How to configure SPF, DKIM and DMARC: step-by-step guide

Someone sends an email from contact@yourdomain.com. The recipient receives the message and 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. They don’t need to hack your mailbox or know a password. The SMTP protocol, designed in 1982, has no sender authentication. It works like a postal letter: anyone can write any return address on the envelope.

In 2025, 3.4 billion phishing emails were sent every day worldwide (Radicati Group, 2025). Most use spoofed domains. And according to a 2024 Agari study, 80% of French company domains lack an active DMARC policy (p=quarantine or p=reject). In other words, 4 out of 5 companies leave their domain open to 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, Squarespace), you can protect your domain in under an hour.

Before you start, test your domain’s current configuration for free. The tool checks your SPF, DKIM, DMARC, and BIMI records in seconds and gives you a score out of 10 with recommendations.

Main points

• Without SPF, DKIM, and DMARC, anyone can send an email pretending to come from your domain, because the SMTP protocol has no sender authentication.
• According to a 2024 Agari study, 80% of French company domains lack an active DMARC policy (p=quarantine or p=reject).
• The protocols do different jobs. SPF lists the servers authorized to send for a domain, DKIM adds a cryptographic signature to each message, and DMARC checks alignment with the From domain and tells receiving servers what to do on failure.
• Roll out DMARC gradually: start at p=none to collect reports, move to p=quarantine, and finish at p=reject once all legitimate sending sources pass checks.
• SPF, DKIM, and DMARC only block exact spoofing of your domain. According to Proofpoint (State of the Phish 2025), 68% of successful phishing attacks in 2024 used legitimate domains, so employee training is still needed alongside them.

What SPF, DKIM and DMARC each do

The three protocols do different things, and none is enough 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 has limits:

• SPF checks the “Return-Path” domain (envelope), not the “From” domain (the header the user sees). 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 matching 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.

DKIM has one advantage over SPF: it survives email forwarding. The signature stays valid after routing through an intermediary server, because it’s attached to the message itself rather than to the server’s IP.

DMARC: the decision policy

DMARC (Domain-based Message Authentication, Reporting & Conformance) doesn’t verify anything on its own. It does two things:

1. 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 the user sees.
2. Policy: it tells receiving servers what to do when an email fails verification:
   • p=none: do nothing (observation only)
   • p=quarantine: send to spam
   • p=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 (it 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

To pass DMARC, an email only needs one of the two checks (SPF or DKIM) to pass with valid alignment. In practice, configure both: SPF covers direct sending, and DKIM covers the cases where the email is forwarded.

Step 1: Inventory your sending sources

Before touching DNS, list every service that sends emails for your domain. If you forget a service, 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:

1. Ask each service: “Do you send emails on behalf of our domain?”
2. Check your domain’s existing SPF/DKIM records (if you have any).
3. 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:

1. Log in to OVH Manager > Domain names > yourdomain.com > DNS Zone
2. Click “Add an entry” > Type TXT
3. Subdomain: leave empty (root)
4. TTL: 3600
5. Value: your complete SPF record
6. Confirm

Cloudflare:

1. Dashboard > select the domain > DNS > Records
2. Add Record > Type TXT > Name: @ > Content: your SPF record
3. Save

Google Domains / Squarespace:

1. DNS > Custom Records > Manage
2. Type TXT > Host name: leave empty > Data: your SPF record
3. 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.

More than 10 lookups

Each include: counts as one lookup, and each include: can itself contain nested include: directives. Google Workspace alone uses 4. If you exceed 10, the result is PermError and SPF is ignored. Count your lookups with a verification tool. If you’re close to the limit, replace include: with direct ip4: or ip6: where possible, or use an SPF flattening service.

No final -all

Without an “all” directive, the record is incomplete. Receiving servers don’t know what to do with unlisted senders, so you get no protection.

Step 3: Configure DKIM

DKIM takes more work than SPF because it needs configuration on both the DNS side (public key) and the sending service side (private key for signing messages).

Google Workspace

1. Admin Console > Apps > Google Workspace > Gmail > Authenticate email
2. Select your domain > “Generate new record”
3. Key length: 2048 bits (recommended)
4. Selector: “google” (default)
5. Google gives you a TXT record to publish under google._domainkey.yourdomain.com
6. Publish the record in your DNS
7. 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:

1. Microsoft Defender > Policies & rules > Threat policies > Email authentication settings > DKIM
2. Select your domain
3. Microsoft gives you two CNAME records to publish:
   • selector1._domainkey.yourdomain.com > selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
   • selector2._domainkey.yourdomain.com > selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
4. Publish the CNAMEs in your DNS
5. Wait for propagation, then enable DKIM signing in the console

Brevo (formerly Sendinblue)

1. Settings > Senders & IP > Domains
2. Add your domain
3. Brevo generates a DKIM (TXT) record for you to publish
4. Publish it in your DNS
5. Click “Verify” in Brevo

Mailjet

1. Account settings > Sending domains > Add a domain
2. Mailjet provides a DKIM TXT record
3. Publish in your DNS
4. 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 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"

What each tag means:

• v=DMARC1: protocol version
• p=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. You can read them, but it’s tedious. Free tools make analysis easier: dmarcian, Postmark DMARC Digests, or simply your email client if volume is low.

What to look for:

1. Lines with disposition=none and dkim=fail or spf=fail from IP addresses you recognize: a legitimate service that’s misconfigured (fix it).
2. 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:

1. p=none for 2 to 4 weeks. Analyze reports. Identify and fix legitimate sources that are failing.
2. p=quarantine; pct=25: send 25% of failing emails to spam. Gradually increase (50%, 75%, 100%).
3. 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:...

Start with adkim=r and aspf=r (relaxed, the default). 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 (optional)

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, which 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 and mostly adds 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, check them in two ways:

1. Our free email testing tool: enter your domain and get a score out of 10 with details for each protocol.
2. A test send: send an email to a Gmail address. Open the email > three-dot menu > “Show original”. You should see:
   • spf=pass
   • dkim=pass
   • dmarc=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

Plain forwarding keeps the DKIM signature intact (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 then compensates for the SPF alignment failure.

Legitimate emails blocked

If your own emails are being blocked after switching to p=reject:

1. Temporarily revert to p=quarantine or p=none
2. Analyze DMARC reports to identify the source
3. Fix the SPF or DKIM configuration for that source
4. Gradually raise the policy back up

What the technical layer doesn’t cover

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.

Most phishing doesn’t need to spoof your domain. According to Proofpoint (State of the Phish 2025), 68% of successful phishing attacks in 2024 used legitimate domains: compromised accounts, lookalike domains registered for the occasion, or hijacked legitimate services (Google Forms, SharePoint, DocuSign).

DNS records can’t stop these attacks. What stops them is your employees’ ability to spot a suspicious email, even when its technical authentication is flawless.

With SPF, DKIM, and DMARC in place, the next step is your team. nophi.sh sends realistic phishing simulations (80 ready-made scenarios in French and English), assigns a short training module to anyone who clicks, and gives you a PDF audit report to track progress.

Quick reference

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	Nothing (displays your logo)

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"

Your next step: run your domain through the grader, fix whatever it flags, then publish a DMARC record at p=none today so the first reports arrive tomorrow.

Check your score now ->