DMARC, DKIM and SPF
– stop email spoofing from your domain

The problem: your domain can be abused without your knowledge

Picture an attacker sending emails to your customers, colleagues, or suppliers. The sender address looks like it comes from your domain. It looks genuine. The recipient has no obvious reason to distrust it.

That's email spoofing. It's possible on virtually any domain that hasn't configured SPF, DKIM and DMARC correctly. The attacker doesn't need access to your systems. They just borrow your identity.

SPF, DKIM and DMARC don't fully eliminate the threat, but they make it significantly harder and give receiving servers something to act on.

The three mechanisms

SPF – who is allowed to send on behalf of your domain

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorised to send email from your domain. When a mail server receives a message from @yourdomain.com, it looks up the SPF record and checks whether the sending server's IP address is on the list.

If it isn't, SPF fails. What happens next depends on your DMARC policy.

Example SPF record for Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

include:spf.protection.outlook.com authorises Microsoft's mail servers to send on your behalf. -all means all other servers should be rejected.

DKIM – a cryptographic signature on your emails

DKIM (DomainKeys Identified Mail) adds a digital signature to the email header. Your mail server signs outgoing emails with a private key. The recipient's server uses the matching public key, published in DNS, to verify the signature.

This proves two things: the email came from a server with access to your private key, and the content hasn't been altered in transit.

The DKIM record in DNS looks like this (Microsoft 365 generates the keys for you):

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

DMARC – the policy that ties it all together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the record that tells receiving servers what to do with emails that fail SPF or DKIM. It also defines reporting, so you can see who is sending email on behalf of your domain.

DMARC has three policies:

• p=none — do nothing, just send reports. Use this while you get started.
• p=quarantine — put failing emails in the spam folder.
• p=reject — reject failing emails outright. This is the goal.

Example DMARC record:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

rua is the address that receives aggregate reports. adkim=s and aspf=s set strict alignment, requiring an exact domain match.

Setup in Microsoft 365 – step by step

Step 1: Verify your SPF record

When you add a domain to Microsoft 365, the setup wizard normally guides you through creating an SPF record. Check that it exists and is correct:

# Look up SPF record (Windows)
nslookup -type=TXT yourdomain.com

# Or with dig (Linux/macOS)
dig TXT yourdomain.com +short

You should see a TXT record containing v=spf1 and include:spf.protection.outlook.com. If it's missing, add it in your DNS panel:

Name: @
Type: TXT
Value: v=spf1 include:spf.protection.outlook.com -all
TTL: 3600

Step 2: Enable DKIM in Microsoft 365 Defender

DKIM is not enabled by default. You need to do it manually.

1. Go to security.microsoft.com
2. Click Email & collaboration in the left menu
3. Click Policies & rules, then Threat policies
4. Under Rules, click DKIM
5. Select your domain and click Enable

Microsoft 365 will ask you to add two CNAME records in DNS. They look like this:

# Record 1
Name: selector1._domainkey
Type: CNAME
Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

# Record 2
Name: selector2._domainkey
Type: CNAME
Value: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Replace yourdomain-com with your actual domain name without dots (e.g. mycompany-com for mycompany.com). Add both records in your DNS panel and wait for propagation — typically 5–60 minutes.

Go back to the DKIM screen in Defender and click Enable again. When status shows "Enabled", you're done.

Step 3: Add the DMARC record

DMARC is configured entirely via DNS. Add a TXT record to your domain:

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]
TTL: 3600

Use your own email address for rua. You'll receive XML reports from receiving servers that process email from your domain. They're not readable in raw form, but free services can parse them for you.

Step 4: Verify everything with MXToolbox

Use MXToolbox SuperTool to check all three records:

spf:yourdomain.com       → checks SPF
dkim:yourdomain.com      → checks DKIM
dmarc:yourdomain.com     → checks DMARC

All three should return green results before you increase the DMARC enforcement level.

Step 5: Tighten DMARC over time

Wait 2–4 weeks while you collect DMARC reports. Analyse them with a free tool like dmarcian or Postmark DMARC. When you're confident that all legitimate mail sources pass, update the DMARC record:

# Phase 2: quarantine
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

# Phase 3: reject (the goal)
v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

pct=25 applies the policy to 25% of failing emails — a good way to test the impact gradually.

Checklist: ready for reject?

• SPF record exists and includes all your mail sources
• DKIM is enabled in Microsoft 365 and CNAME records are added
• DMARC record is added with p=none and an rua address
• You've collected and analysed DMARC reports for 2–4 weeks
• No legitimate mail sources are failing SPF or DKIM in the reports
• DMARC updated to p=quarantine, monitored for another 1–2 weeks
• DMARC updated to p=reject

What it doesn't fix

SPF, DKIM and DMARC protect the From: address in the header — the visible sender. They don't protect against lookalike domains like yourcompany-support.com or yourcompanysec.com that resemble your domain but aren't it.

They also don't stop phishing from compromised accounts within your own domain. An attacker with access to one account can still send convincing phishing to your colleagues.

But they close the obvious door that's otherwise wide open: the ability to send arbitrary email as @yourdomain.com with no authentication whatsoever.

Sources

• Microsoft: Set up DKIM to sign mail from your Microsoft 365 domain
• Microsoft: Use DMARC to validate email in Microsoft 365
• RFC 7489 – DMARC specification
• MXToolbox SuperTool – verify SPF, DKIM and DMARC