9.6 Email Authentication: SPF, DKIM, DMARC

Email Authentication: SPF, DKIM, DMARC

By the end of this subsection, you will understand what each email authentication protocol verifies, know why passing authentication does not mean the email is safe, and be able to configure DMARC for your domain.

The three protocols

Configuring DMARC for your domain

DMARC protects YOUR domain from being spoofed by others. It tells receiving mail servers what to do when someone sends email claiming to be from your domain but fails SPF/DKIM alignment.

DMARC policy levels:

Common DMARC deployment mistakes

Analyzing authentication results with KQL

1
2
3
4
5
6
7

EmailEvents
| where TimeGenerated > ago(7d)
| where SenderFromDomain != SenderMailFromDomain
| project TimeGenerated, SenderFromAddress, SenderMailFromAddress,
    SenderFromDomain, SenderMailFromDomain,
    AuthenticationDetails, Subject
| take 20

Practical DMARC deployment timeline

Required role and blast radius

Required role: Exchange Administrator (for DKIM signing configuration). DNS Administrator (for SPF/DKIM/DMARC record changes). These are typically different people — coordinate.

SPF — practical implementation

SPF tells receiving mail servers which IPs are authorised to send email for your domain. The receiving server checks: did this email come from an IP listed in the domain’s SPF record?

Your SPF record: Check current: nslookup -type=txt northgateeng.com (or use MXToolbox). A typical M365-only SPF record: v=spf1 include:spf.protection.outlook.com -all.

Common additions for M365 environments:

• Third-party email marketing (Mailchimp): add include:servers.mcsv.net
• CRM (Salesforce): add include:_spf.salesforce.com
• Helpdesk (Zendesk): add include:mail.zendesk.com
• Transactional email (SendGrid): add include:sendgrid.net

The 10-lookup limit. SPF allows a maximum of 10 DNS lookups. Each include: counts as 1+ lookups (the included record may itself contain includes). Exceeding 10 causes SPF permerror — your email fails authentication. Monitor your lookup count as you add senders. If you approach 10: use IP addresses directly (ip4:203.0.113.0/24) instead of includes, or use an SPF flattening service.

Blast radius of SPF changes: If misconfigured: email from your domain fails SPF checks. Receiving servers may reject or junk your outbound email. Test changes by adding senders incrementally and monitoring delivery.

Rollback: Revert the DNS TXT record to the previous version. DNS propagation takes 5-60 minutes.

DKIM — practical implementation

DKIM adds a cryptographic signature to outbound email. The receiving server verifies the signature against the public key in your DNS — confirming the email was not modified in transit and genuinely originated from your infrastructure.

Enable DKIM for M365: Navigate to Defender → Email & collaboration → Policies → DKIM. Select your domain. Enable DKIM signing. M365 generates the key pair and provides the CNAME records to add to DNS.

Verify: After adding DNS records and enabling: send a test email to an external account. Check the email headers for dkim=pass.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// Monitor DKIM pass/fail rates for your outbound email
EmailEvents
| where TimeGenerated > ago(30d)
| where SenderFromDomain == "northgateeng.com"
| extend AuthDetails = parse_json(AuthenticationDetails)
| extend DKIMResult = tostring(AuthDetails.DKIM)
| summarize
    Total = count(),
    DKIMPass = countif(DKIMResult == "pass"),
    DKIMFail = countif(DKIMResult == "fail"),
    DKIMNone = countif(DKIMResult == "none" or isempty(DKIMResult))
    by bin(TimeGenerated, 7d)

Target: 100% DKIMPass for email sent through M365. DKIMFail indicates a configuration issue (key mismatch, DNS record incorrect). DKIMNone indicates email sent through a system that is not DKIM-signed (a third-party sender not configured for DKIM with your domain).

DMARC — the enforcement layer

DMARC tells receiving servers what to do when email fails both SPF and DKIM. Without DMARC: the receiving server decides (usually delivers to junk or delivers normally). With DMARC at p=reject: the receiving server blocks the email entirely.

DMARC deployment path:

Month 1: v=DMARC1; p=none; rua=mailto:dmarc-reports@northgateeng.com. Monitor-only. Collect aggregate reports showing who sends email using your domain. Identify legitimate senders not covered by SPF/DKIM.

Month 2-3: Fix any legitimate senders failing DMARC (add to SPF, enable DKIM). Re-review aggregate reports: are all legitimate senders passing?

Month 4: p=quarantine. Failing email goes to junk. Monitor for reports of missing legitimate email.

Month 6: p=reject. Failing email is blocked entirely. Your domain is now protected against spoofing.

Do not skip to p=reject on day one. Legitimate email that fails DMARC (a marketing platform not yet added to SPF) will be silently blocked. The monitor period identifies these senders before enforcement breaks business communication.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Check inbound DMARC results for email claiming to be from your domain
EmailEvents
| where TimeGenerated > ago(30d)
| where SenderFromDomain == "northgateeng.com"
| extend AuthDetails = parse_json(AuthenticationDetails)
| extend DMARCResult = tostring(AuthDetails.DMARC)
| extend CompAuth = tostring(AuthDetails.CompAuth)
| where DMARCResult != "pass"
| project TimeGenerated, SenderFromAddress, SenderIPv4,
    DMARCResult, CompAuth, Subject

Any email claiming to be from your domain that fails DMARC is either: a legitimate sender misconfigured (fix the SPF/DKIM), or an attacker spoofing your domain (the exact attack DMARC prevents once at p=reject).

Common SPF/DKIM/DMARC troubleshooting

Problem: SPF PermError. Your SPF record exceeds 10 DNS lookups. Symptoms: some recipients reject your email, others junk it.

Diagnosis: nslookup -type=txt northgateeng.com — count each include: and recursively count their includes. Or use MXToolbox SPF record checker.

Fix: Replace include: directives with direct IP addresses where possible. Or use an SPF flattening service (these resolve all includes into a flat list of IPs and maintain the record automatically).

Problem: DKIM failing for third-party senders. Your marketing platform sends email “from” your domain but the DKIM signature uses their domain, not yours.

Fix: Configure the third-party platform to sign with your domain’s DKIM key. Most platforms support this: upload your DKIM public key to their configuration, or delegate a subdomain (e.g., em.northgateeng.com) and configure DKIM for the subdomain.

Problem: DMARC reports show legitimate senders failing. You moved to p=quarantine and a vendor’s email is being junked.

Fix: Add the vendor’s sending IPs to your SPF record, or configure the vendor to sign with DKIM using your domain or a DMARC-aligned domain. Do NOT move back to p=none — instead, fix the alignment for the specific sender while maintaining enforcement for everyone else.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// DMARC failure investigation: who is failing authentication?
EmailEvents
| where TimeGenerated > ago(7d)
| where SenderFromDomain == "northgateeng.com"
| extend AuthDetails = parse_json(AuthenticationDetails)
| extend SPF = tostring(AuthDetails.SPF)
| extend DKIM = tostring(AuthDetails.DKIM)
| extend DMARC = tostring(AuthDetails.DMARC)
| where DMARC != "pass"
| summarize
    FailCount = count(),
    SenderIPs = make_set(SenderIPv4, 10)
    by SenderFromAddress, SPF, DKIM, DMARC
| order by FailCount desc

This query identifies exactly which senders are failing DMARC and why (SPF fail, DKIM fail, or both). Use the SenderIPs to identify the sending system — then fix its SPF or DKIM configuration.

The business case for email authentication

SPF, DKIM, and DMARC are not just security controls — they are business reputation controls.

Without DMARC enforcement: Anyone can send email that appears to come from your domain. Attackers use this for: phishing your partners (they receive email “from” you with malicious content), BEC against your customers (they receive invoice changes “from” your domain), and brand damage (your domain appears in spam campaigns).

With DMARC at p=reject: Only authorised senders can send email using your domain. Spoofed email is blocked by the recipient’s mail server before delivery. Your domain reputation is protected.

The cost of NOT implementing DMARC: If your domain is spoofed in a phishing campaign targeting your customers, the reputational damage is significant — customers lose trust in email from your domain. Additionally, email deliverability degrades: major email providers (Google, Microsoft) increasingly penalise domains without DMARC enforcement by routing their email to junk.

UK government requirement: The UK National Cyber Security Centre (NCSC) recommends DMARC at p=quarantine or p=reject for all UK organisations. Government departments and their suppliers are increasingly required to have DMARC enforcement. Cyber Essentials Plus certification requires email authentication controls.

DMARC aggregate report analysis

DMARC aggregate reports arrive daily (or weekly, depending on the ri= tag in your DMARC record). Each report is an XML file from a receiving mail server showing: how many emails it received claiming to be from your domain, whether SPF and DKIM passed or failed for each, and what action it took (delivered, quarantined, rejected).

Manual analysis is impractical — you may receive 10-50 reports per day from different mail servers. Use a DMARC analysis service: dmarcian, Valimail, Agari, or PowerDMARC. These services aggregate reports into dashboards showing: total sending volume per source, pass/fail rates, and unauthenticated senders.

Free option: Parse reports with PowerShell or Python. Microsoft does not provide a built-in DMARC report analyser. The open-source tool parsedmarc converts XML reports into human-readable format.

What to look for in DMARC reports:

Legitimate senders failing authentication → fix their SPF/DKIM alignment. Unknown senders passing authentication → investigate (a compromised account or an authorised sender you forgot about). Unknown senders failing authentication → these are spoofing attempts that DMARC enforcement blocks. The volume and origin of these attempts informs your threat model.