How to Configure SPF, DKIM, and DMARC: The Complete Guide to Protecting Your Email Domain
Step-by-step technical guide to configuring SPF, DKIM, and DMARC on your domain. Concrete examples for OVH, Google Workspace, and Microsoft 365. Verification and troubleshooting included.
Someone sends an email from contact@yourdomain.com. The recipient receives the message, sees your name, your address, maybe even your logo. The problem: you didn't send it.
Without SPF, DKIM, and DMARC, anyone can send an email pretending to be your domain. No need to hack your mailbox. No password required. The SMTP protocol, designed in 1982, includes no sender authentication mechanism. It's exactly like a postal letter: anyone can write any return address on the envelope.
In 2025, 3.4 billion phishing emails are sent every day worldwide (Radicati Group, 2025). Most use spoofed domains. And according to an Agari study from 2024, 80% of French company domains lack an active DMARC policy (p=quarantine or p=reject). In other words, 4 out of 5 companies leave the door wide open for email impersonation.
This guide walks you through configuring SPF, DKIM, and DMARC step by step. You don't need to be a DNS expert. If you know how to add a TXT record in your registrar's interface (OVH, Gandi, Cloudflare, Google Domains), you can protect your domain in under an hour.
Before you start, test your domain's current configuration for free. Our tool checks your SPF, DKIM, DMARC, and BIMI records in seconds and gives you a score out of 10 with recommendations.
Understanding the SPF, DKIM, DMARC trio
Before configuring anything, a clear understanding of what each protocol does is essential. They don't do the same thing, and none is sufficient on its own.
SPF: who is allowed to send?
SPF (Sender Policy Framework) is a TXT DNS record published at the root of your domain. It lists the IP addresses and domains authorized to send emails on your behalf.
When a server receives an email claiming to come from @yourdomain.com, it looks up the SPF record for yourdomain.com and checks whether the sending server's IP is on the list. If yes, the SPF check passes. If not, it fails.
Example SPF record:
v=spf1 include:_spf.google.com include:spf.brevo.com -all
This record authorizes Google Workspace and Brevo to send emails for the domain. All other servers are rejected (-all).
SPF limitations:
- SPF checks the "Return-Path" domain (envelope), not the "From" domain (the header visible to the user). An attacker can use a legitimate Return-Path while displaying a fake From address.
- SPF does not survive email forwarding. When an email is forwarded, the intermediary server's IP is not in the original domain's SPF record, and the check fails.
- SPF is limited to 10 DNS lookups (recursive resolutions). Beyond that, the check automatically fails (PermError result).
DKIM: has the message been tampered with?
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each outgoing email. The sending server signs the message with a private key. The corresponding public key is published in DNS as a TXT record.
When a server receives the email, it retrieves the public key from DNS and verifies that the signature matches the message content. If someone has modified the body or headers of the email in transit, the signature no longer matches.
Example DKIM record:
google._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBg..."
The selector (here "google") identifies which key to use. A domain can have multiple selectors for different sending services.
Advantage over SPF: DKIM survives email forwarding. The signature remains valid even after routing through an intermediary server, because it's attached to the message itself, not to the server's IP.
DMARC: the decision policy
DMARC (Domain-based Message Authentication, Reporting & Conformance) is the conductor. It doesn't verify anything on its own. It does two things:
- Alignment: it checks that the domain in the "From" header matches the domain validated by SPF or DKIM. Without DMARC, an email can pass SPF (on the Return-Path) while displaying a fraudulent domain in the From header visible to the user.
- Policy: it tells receiving servers what to do when an email fails verification:
p=none- do nothing (observation only)p=quarantine- send to spamp=reject- refuse the message
Example DMARC record:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1"
This record tells servers to reject any email that fails verification, and to send aggregate reports to dmarc@yourdomain.com.
Without DMARC, SPF and DKIM only do half the job. An attacker can send an email with a Return-Path under a domain they control (passes SPF on their own domain) while displaying your address in the From header. Without DMARC, the receiving server has no instructions to block this message.
How the three work together
Email received by the destination server
|
1. SPF check: is the sender's IP authorized?
|
2. DKIM check: is the cryptographic signature valid?
|
3. DMARC check:
- Is the From domain aligned with SPF or DKIM?
- If yes -> email accepted
- If no -> apply policy (none/quarantine/reject)
|
4. DMARC report sent to the domain owner
An email only needs to pass one of the two checks (SPF or DKIM) with valid alignment to be accepted by DMARC. It's an "OR", not an "AND". In practice, configure both: SPF for simple cases, DKIM for cases where the email is forwarded.
Step 1: Inventory your sending sources
Before touching DNS, list every service that sends emails for your domain. Forgetting a service means its emails will be blocked when you enforce a strict policy.
Common sources:
| Category | Examples | Typical SPF mechanism |
|---|---|---|
| Main email | Google Workspace, Microsoft 365 | include:_spf.google.com or include:spf.protection.outlook.com |
| Marketing / newsletter | Brevo, Mailjet, Mailchimp, HubSpot | include:spf.brevo.com, include:servers.mcsv.net |
| Transactional | SendGrid, Postmark, Amazon SES | include:sendgrid.net, include:amazonses.com |
| CRM | Salesforce, Pipedrive, HubSpot | include:_spf.salesforce.com |
| Support | Zendesk, Freshdesk, Intercom | include:mail.zendesk.com |
| Invoicing | Stripe, QuickBooks, Pennylane | Varies by service |
| Application server | VPS, dedicated server | ip4:X.X.X.X |
How to find them:
- Ask each service: "Do you send emails on behalf of our domain?"
- Check your domain's existing SPF/DKIM records (if you have any).
- If you already have a DMARC record in p=none with rua=, analyze the reports to discover sending sources you forgot.
Step 2: Configure SPF
Build the record
The format is strict: a single TXT record at the domain root, starting with v=spf1, followed by authorization mechanisms, ending with a -all or ~all directive.
For Google Workspace:
v=spf1 include:_spf.google.com -all
For Microsoft 365:
v=spf1 include:spf.protection.outlook.com -all
For Google Workspace + Brevo + a dedicated server:
v=spf1 include:_spf.google.com include:spf.brevo.com ip4:203.0.113.42 -all
Publish in DNS
The procedure varies by registrar.
OVH:
- Log in to OVH Manager > Domain names > yourdomain.com > DNS Zone
- Click "Add an entry" > Type TXT
- Subdomain: leave empty (root)
- TTL: 3600
- Value: your complete SPF record
- Confirm
Cloudflare:
- Dashboard > select the domain > DNS > Records
- Add Record > Type TXT > Name: @ > Content: your SPF record
- Save
Google Domains / Squarespace:
- DNS > Custom Records > Manage
- Type TXT > Host name: leave empty > Data: your SPF record
- Save
Common mistakes
Two SPF records. A domain must have only one SPF record. If you already have an SPF record and need to add a service, modify the existing record by adding another include:. Do not create a second TXT record starting with v=spf1.
Exceeding 10 lookups. Each include: counts as one lookup. Each include: can itself contain nested include: directives. Google Workspace alone consumes 4. If you exceed 10, the result is PermError and SPF is ignored. Count your lookups with a verification tool. If you're approaching the limit, replace include: with direct ip4: or ip6: where possible, or use an SPF flattening service.
Forgetting the final -all. Without an "all" directive, the record is incomplete. Receiving servers don't know what to do with unlisted senders. Result: no protection.
Step 3: Configure DKIM
DKIM is more complex than SPF because it requires configuration on both the DNS side (public key) and the sending service side (private key for signing messages).
Google Workspace
- Admin Console > Apps > Google Workspace > Gmail > Authenticate email
- Select your domain > "Generate new record"
- Key length: 2048 bits (recommended)
- Selector: "google" (default)
- Google gives you a TXT record to publish under
google._domainkey.yourdomain.com - Publish the record in your DNS
- Wait 15 to 60 minutes, then return to the Admin console and click "Start authentication"
DNS record to create:
Type: TXT
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBg... (the key provided by Google)
Microsoft 365
Microsoft 365 enables DKIM automatically for *.onmicrosoft.com domains. For your custom domain:
- Microsoft Defender > Policies & rules > Threat policies > Email authentication settings > DKIM
- Select your domain
- Microsoft gives you two CNAME records to publish:
selector1._domainkey.yourdomain.com>selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.comselector2._domainkey.yourdomain.com>selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
- Publish the CNAMEs in your DNS
- Wait for propagation, then enable DKIM signing in the console
Brevo (formerly Sendinblue)
- Settings > Senders & IP > Domains
- Add your domain
- Brevo generates a DKIM (TXT) record for you to publish
- Publish it in your DNS
- Click "Verify" in Brevo
Mailjet
- Account settings > Sending domains > Add a domain
- Mailjet provides a DKIM TXT record
- Publish in your DNS
- Validate
Verify that DKIM is working
Send an email to a Gmail address from your domain. Open the received email > three-dot menu > "Show original". Look for the line dkim=pass. If you see dkim=fail or DKIM doesn't appear, signing is not active.
You can also use our DNS verification tool, which automatically detects common DKIM selectors and verifies that the key is published.
Step 4: Configure DMARC
The starter record
Start with a non-blocking policy to observe before enforcing:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1"
Meaning:
v=DMARC1- protocol versionp=none- policy: observe but don't block (testing phase)rua=mailto:dmarc-reports@yourdomain.com- address for receiving aggregate reports (XML, sent daily by receiving servers)fo=1- send a failure report for each email that fails (useful for diagnosis)
Publish in DNS
As with SPF, add a TXT record to your DNS zone:
| Type | Name | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1 |
Analyze the reports
DMARC reports are XML files sent by mail servers (Gmail, Microsoft, Yahoo, etc.) that process emails claiming to come from your domain. They contain:
- The sender server's IP
- SPF result (pass/fail)
- DKIM result (pass/fail)
- DMARC alignment (pass/fail)
- Number of emails per source
Raw reports are XML files compressed in ZIP or GZ format. They're readable but not practical. Free tools make analysis easier: DMARC Analyzer (dmarcian), Postmark DMARC, or simply your email client if volume is low.
What to look for:
- Lines with
disposition=noneanddkim=failorspf=failfrom IP addresses you recognize - a legitimate service that's misconfigured (fix it). - Lines with unknown IPs and
dkim=fail+spf=fail- spoofing attempts (exactly what DMARC is supposed to block).
Gradually raise the policy
The recommended process:
- p=none for 2 to 4 weeks. Analyze reports. Identify and fix legitimate sources that are failing.
- p=quarantine; pct=25 - send 25% of failing emails to spam. Gradually increase (50%, 75%, 100%).
- p=reject - fully block fraudulent emails. This is the end goal.
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@yourdomain.com; fo=1
Then, when you're confident:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; fo=1
Advanced DMARC options
| Parameter | Description | Example |
|---|---|---|
sp= | Policy for subdomains | sp=reject |
adkim= | DKIM alignment strict (s) or relaxed (r) | adkim=s |
aspf= | SPF alignment strict (s) or relaxed (r) | aspf=r |
pct= | Percentage of emails subject to the policy | pct=50 |
ruf= | Address for individual failure (forensic) reports | ruf=mailto:... |
Recommendation: adkim=r and aspf=r (relaxed, the default) to start. Relaxed mode accepts subdomains (e.g., mail.yourdomain.com passes alignment for yourdomain.com). Switch to strict only if you have full control over your subdomains.
Step 5: Configure BIMI (bonus)
BIMI (Brand Indicators for Message Identification) displays your logo next to your emails in compatible clients (Gmail, Yahoo, Apple Mail since iOS 16).
Prerequisites:
- DMARC at p=quarantine or p=reject (required)
- A logo in SVG Tiny PS format (specific profile)
- A VMC (Verified Mark Certificate) for Gmail - costs approximately EUR 1,500 per year from DigiCert or Entrust
BIMI record:
default._bimi.yourdomain.com TXT "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/vmc.pem"
BIMI is optional but reinforces visual trust. For SMEs, the priority is SPF + DKIM + DMARC at p=reject. BIMI can wait.
Verification and troubleshooting
Verify your configuration
After publishing your records, verify:
- Our free email testing tool - enter your domain and get a score out of 10 with details for each protocol.
- Send test - send an email to a Gmail address. Open the email > three-dot menu > "Show original". You should see:
spf=passdkim=passdmarc=pass
Common issues
SPF: PermError (too many lookups)
Count the total number of DNS lookups. Each include:, a:, mx:, ptr: (deprecated), and exists: counts as one lookup. ip4: and ip6: do not count. If you exceed 10, consolidate by replacing include: directives with direct ip4: entries or use an SPF flattening service.
DKIM: fail after forwarding
Email forwarding does not break DKIM (unlike SPF). If DKIM fails after forwarding, the intermediary server has modified the message content (added a disclaimer, altered headers). Check your server's transport rules.
DMARC: alignment fail
DMARC alignment checks that the domain in the "From" header matches the domain validated by SPF or DKIM. If your sending service uses a different domain in the Return-Path (e.g., bounce.sendinblue.com), SPF will pass but SPF alignment will fail. In this case, make sure DKIM is configured with a selector under your domain - DKIM alignment will compensate for the SPF alignment failure.
Legitimate emails blocked
If your own emails are being blocked after switching to p=reject:
- Temporarily revert to
p=quarantineorp=none - Analyze DMARC reports to identify the source
- Fix the SPF or DKIM configuration for that source
- Gradually raise the policy back up
The technical layer is not enough
SPF, DKIM, and DMARC protect against one type of attack: exact spoofing of your domain. An attacker sending an email from contact@yourdomain.com will be blocked.
But modern phishing goes far beyond domain spoofing. In 2024, 68% of successful phishing attacks used legitimate domains (Proofpoint State of the Phish 2025) - compromised accounts, lookalike domains registered for the occasion, or hijacked legitimate services (Google Forms, SharePoint, DocuSign).
Against these attacks, the technical layer is blind. The human layer makes the difference: your employees' ability to spot a suspicious email, even when the technical authentication is flawless.
You've configured SPF, DKIM, and DMARC. The technical layer is in place. Now, protect the human layer with nophi.sh - automated phishing simulation, targeted micro-training, and measurable team progress.
Summary
| Protocol | DNS type | Location | Protects against |
|---|---|---|---|
| SPF | TXT | @ (root) | Sending from unauthorized servers |
| DKIM | TXT or CNAME | selector._domainkey | Message content modification in transit |
| DMARC | TXT | _dmarc | Spoofing of the visible domain (From) |
| BIMI | TXT | default._bimi | - (displays logo, not a protection) |
Recommended minimum configuration:
@ TXT "v=spf1 include:_spf.google.com -all"
google._domainkey TXT "v=DKIM1; k=rsa; p=..."
_dmarc TXT "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1"
Three records. Under an hour of work. And your domain goes from "anyone can impersonate your identity" to "fraudulent emails are automatically rejected."