SPF, DKIM, and DMARC: Stop Attackers Spoofing Your Domain

Right now, without any hacking, exploitation, or credential theft, an attacker can send an email that appears to come from your domain. The "From" field in email is self-declared — the sending server simply states who the email is from, and without authentication, there's no verification. This is how phishing campaigns impersonate banks, how business email compromise scams cost billions annually, and how your domain can be weaponised against your own customers. SPF, DKIM, and DMARC are the three protocols that fix this.

SPF: Declaring Who Can Send

Sender Policy Framework (SPF) publishes a DNS TXT record that lists the IP addresses and servers authorised to send email for your domain. When a receiving mail server gets an email claiming to be from yourdomain.com, it checks the SPF record to see if the sending server's IP is listed.

v=spf1 include:_spf.google.com include:sendgrid.net -all

This record says: Google Workspace and SendGrid are authorised senders. The -all at the end means reject everything else. Many domains use ~all (soft fail) instead, which flags but doesn't reject unauthorised senders — significantly weakening the protection.

SPF has limitations. It checks the envelope sender (the Return-Path header), not the visible "From" address that users see. An attacker can set the envelope sender to their own domain (passing SPF) while displaying your domain in the From header. SPF alone doesn't prevent visible domain spoofing.

DKIM: Cryptographic Signatures

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to email headers. The sending server signs the email with a private key, and the receiving server verifies the signature using a public key published in DNS.

DKIM proves two things: the email was sent by someone with access to the domain's private key, and the email hasn't been modified in transit. If an attacker modifies the email body or headers after signing, the signature breaks and the email fails DKIM verification.

Like SPF, DKIM alone has gaps. It doesn't tell the receiving server what to do if verification fails. An email with a broken DKIM signature might still be delivered — the receiving server doesn't know whether the domain owner wants strict enforcement or considers DKIM optional.

DMARC: The Policy Layer

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. It also solves the alignment problem — requiring that the domain in the visible "From" header matches the domain verified by SPF or DKIM.

v=DMARC1; p=reject; rua=mailto:dmarc-reports(at)yourdomain.com; adkim=s; aspf=s

This record instructs receiving servers to reject emails that fail both SPF and DKIM alignment checks, and send aggregate reports to your monitoring address. The p=reject policy is the strongest enforcement — it tells servers to discard spoofed emails entirely.

The three enforcement levels are:

• p=none: Monitor only. Spoofed emails are delivered normally. Useful during initial deployment to identify legitimate sending sources, but provides zero protection.
• p=quarantine: Spoofed emails are sent to spam. Better than none, but sophisticated phishing targets the inbox, not spam.
• p=reject: Spoofed emails are discarded. The goal state that prevents your domain from being used in phishing campaigns.

The Deployment Path

Moving from no email authentication to p=reject requires careful progression:

1. Inventory all sending sources: Your domain likely sends email from more places than you realise — marketing platforms, CRM systems, transactional email services, support ticketing, internal applications. Each one needs to be included in SPF and configured with DKIM.
2. Deploy with p=none: Start DMARC in monitoring mode and analyse reports to identify all legitimate senders and any authentication failures.
3. Fix alignment issues: Ensure all legitimate senders pass SPF or DKIM with proper domain alignment.
4. Escalate to p=quarantine: Move spoofed emails to spam while monitoring for false positives — legitimate emails incorrectly quarantined.
5. Enforce p=reject: Once confidence is high that all legitimate email passes authentication, reject spoofed messages.

This process typically takes 2-4 weeks for simple domains and 2-3 months for organisations with complex email infrastructure.

The Cost of Not Implementing

Without email authentication, your domain is an open weapon. The consequences extend beyond phishing:

• Deliverability degradation: Major email providers (Google, Microsoft, Yahoo) now require SPF, DKIM, and DMARC for bulk senders. Without them, even your legitimate emails may land in spam.
• Brand damage: Customers who receive phishing emails from "your" domain lose trust in your brand, regardless of whether you sent them.
• Regulatory exposure: GDPR and other regulations require appropriate security measures. Allowing your domain to be spoofed in phishing attacks targeting your customers can be construed as a failure to protect their data.
• Domain reputation: Email reputation systems track how often a domain is associated with spam and phishing. A domain without DMARC enforcement accumulates negative reputation as attackers abuse it.

ShieldReport checks your domain's SPF, DKIM, and DMARC configuration, identifying missing records, weak policies, and alignment issues that leave your domain vulnerable to spoofing — so you can protect your customers and your brand from email-based attacks.