Email was designed in the 1970s with a trust model that assumed everyone on the network was trustworthy. The SMTP protocol allows anyone to put any email address in the From: header — there's no built-in verification that the sender actually controls that address. This makes email spoofing trivially easy and is the foundation of most phishing attacks.
Every day, billions of spoofed emails are sent worldwide. Attackers impersonate banks, payment processors, colleagues, and well-known brands to trick recipients into revealing credentials, transferring money, or installing malware. The consequences range from individual account compromise to massive data breaches and financial fraud.
To combat this, the email industry developed DNS-based authentication standards that let domain owners declare which mail servers are authorized to send email on their behalf. The three core standards — SPF, DKIM, and DMARC — work together to verify sender identity and give receiving servers a framework for deciding what to do with unauthenticated mail.
SPF is a DNS TXT record that lists the IP addresses and mail servers authorized to send email from your domain. When a receiving mail server gets a message, it checks the SPF record of the domain in the envelope sender address (MAIL FROM) and verifies that the message originated from an authorized server.
A basic SPF record looks like this:
v=spf1 include:_spf.google.com ~all
This record says: authorized senders include all IPs listed in Google's SPF record, and other servers should be treated with suspicion (~all). SPF mechanisms include:
ip4: and ip6: — authorize specific IP addresses or ranges.include: — reference another domain's SPF record (for third-party senders like Google Workspace, Mailchimp, or SendGrid).a: and mx: — authorize the domain's own A record IPs or MX server IPs.+all (pass), ~all (softfail), -all (fail), ?all (neutral) — the all mechanism determines what happens for unauthorized senders.SPF's main limitation is that it only checks the envelope sender, not the visible From: header that users see. An attacker can pass SPF while spoofing the display name and From: address. This is where DMARC comes in.
DKIM adds a cryptographic signature to outgoing emails. When your mail server sends a message, it generates a hash of selected headers and the body, signs it with a private key, and adds the signature as a DKIM-Signature header. The corresponding public key is published in a DNS TXT record under default._domainkey.yourdomain.com.
When a receiving server gets the message, it retrieves the public key from DNS, recomputes the hash, and verifies the signature. If it matches, the message hasn't been tampered with in transit and was indeed sent by a server that holds the private key.
Key aspects of DKIM:
From:, To:, Subject:, and Date: are signed. If any signed header is modified, the signature breaks.DMARC ties SPF and DKIM together with a policy that tells receiving servers what to do when authentication fails. It's published as a DNS TXT record at _dmarc.yourdomain.com and includes:
p): none (monitor only, don't block), quarantine (send to spam/junk), or reject (don't deliver). Most domains should start at p=none to monitor, then move to quarantine and eventually reject.From: header aligns with either the SPF-checked domain (strict alignment) or the DKIM signing domain (relaxed alignment, same domain or subdomain).rua and ruf): Aggregate reports (rua) are daily XML summaries of authentication results. Forensic reports (ruf) are sent immediately for individual failures (sensitive — rarely used).A recommended DMARC record: v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100
For a deeper walkthrough of setup and configuration, see our full SPF, DKIM & DMARC guide.
To verify your domain's email authentication is properly configured, you can check several things:
dig TXT yourdomain.com and look for a record starting with v=spf1. Ensure it has an -all or ~all mechanism. Avoid +all (allows anyone).dig TXT default._domainkey.yourdomain.com and verify a public key is published. Send a test email to an address that returns authentication results (like Gmail's gmail-smtp-in.l.google.com).dig TXT _dmarc.yourdomain.com and verify the policy. Check aggregate reports at the rua address for authentication data.dig MX yourdomain.com. Invalid MX records cause delivery failures.Use our MX Validator to check your mail exchange records and our detailed email authentication guide for step-by-step DMARC deployment instructions.