Email was designed in the 1970s with no authentication mechanism — anyone can send an email claiming to be from any address. This makes email spoofing trivially easy: a criminal can send messages appearing to come from your-bank.com, your-company.com, or even a government agency.
Three DNS-based standards were created to combat this: SPF, DKIM, and DMARC. Together they form a chain of trust that allows receiving mail servers to verify whether an email truly came from the domain it claims to represent.
Without these records, your domain is vulnerable to being used in phishing campaigns — and your legitimate emails may be marked as spam. Major email providers (Gmail, Microsoft 365, Yahoo) increasingly require DMARC to deliver to the inbox reliably.
SPF is a DNS TXT record that lists which mail servers are authorised to send email on behalf of your domain. When a receiving server gets an email claiming to be from example.com, it checks example.com's SPF record to see if the sending server's IP is listed.
| Part | Meaning |
|---|---|
| v=spf1 | SPF version (always spf1) |
| include:_spf.google.com | Allow all IPs in Google's SPF record (for Gmail) |
| include:sendgrid.net | Allow SendGrid to send on your behalf |
| ip4:203.0.113.5 | Allow this specific IPv4 address |
| -all | Hard fail — reject all other senders |
| Qualifier | Result | Recommendation |
|---|---|---|
| -all | Hard fail — reject | Best for enforced domains |
| ~all | Soft fail — accept but mark | Transition / testing |
| ?all | Neutral — no policy | Avoid |
| +all | Pass — allow everyone | Never use |
DKIM adds a cryptographic signature to every outgoing email. The receiving server can verify this signature using a public key published in the sending domain's DNS. If the signature is valid, the email content hasn't been tampered with in transit and it was sent by an authorised server.
The selector (here: default) allows a domain to have multiple DKIM keys — useful for different sending services. Google uses google, SendGrid uses its own selector, etc.
DMARC ties SPF and DKIM together and adds a policy for what to do with emails that fail authentication. It also enables reporting — you receive reports from other mail servers about who is sending email using your domain.
DMARC requires that either SPF or DKIM must align with the From: header domain. This closes the gap that SPF alone leaves — an attacker could pass SPF with a different domain, but DMARC checks that the authenticated domain matches the visible From: address.
| Tag | Meaning |
|---|---|
| v=DMARC1 | DMARC version |
| p=reject | Policy: reject failing emails (quarantine = spam folder; none = no action) |
| rua=mailto:... | Aggregate reports sent here (daily XML summary) |
| ruf=mailto:... | Forensic reports sent here (per-failure details) |
| pct=100 | Apply policy to 100% of failing emails |
| adkim=s | DKIM alignment: strict (domain must exactly match) |
| aspf=s | SPF alignment: strict |
Think of them as three layers of protection:
An attacker trying to spoof your domain would need to either have access to your DKIM private key, or be listed in your SPF record, or compromise your mail server — all of which are significantly harder than simply forging a From: address.
You can inspect SPF and DMARC records for any domain using ip-tracker.eu — enter the domain name and check the Email Security section for SPF and DMARC status.
From the command line:
Common issues to look for:
A domain lookup in IP-Tracker.eu retrieves live TXT records and highlights SPF and DMARC when they are present. This makes it possible to quickly verify whether the domain publishes basic sender authentication policies.
When reviewing the result, check whether an SPF record exists and whether the domain publishes a DMARC policy under _dmarc.example.com. The presence of records alone does not guarantee a secure configuration — the policy and permitted senders also matter.
Check any domain's SPF & DMARC records
Instant DNS lookup including email security status — free, no registration.
Check Domain Security →