What Are SPF, DKIM and DMARC? Corporate Email Security Explained

SPF, DKIM and DMARC are three DNS-based email authentication standards that work together to prove an email genuinely came from your domain and to block forged or spoofed messages. If your organisation sends email from a custom domain, configuring SPF DKIM DMARC is the single most effective way to protect your brand from impersonation, keep your legitimate messages out of the spam folder, and shut down the phishing attacks that abuse your company name. In this guide we explain what each standard does, how they interact, what the DNS records look like, and the step-by-step process to deploy them correctly.

Why email needs authentication in the first place

Email was designed in an era of mutual trust. The core sending protocol, SMTP, never included a built-in way to verify that the sender is who they claim to be. As a result, anyone on the internet can craft a message with your domain in the From field and send it to your customers, suppliers or employees. This is called email spoofing, and it is the foundation of most business email compromise (BEC) and phishing campaigns.

A typical attack works like this: a criminal sends an invoice or a payment-change request that appears to come from [email protected]. The recipient sees a familiar address, trusts it, and wires money to the attacker's account. Because the underlying protocol offers no verification, the mailbox provider has no reliable way to tell the fake message from a real one — unless your domain publishes authentication records that tell it exactly which servers are allowed to send on your behalf.

That is precisely the gap SPF, DKIM and DMARC close. They add a verifiable layer of identity on top of ordinary email, published as records in your domain's DNS. Any receiving server can look them up, run the checks, and decide whether to deliver, quarantine or reject the message.

What is SPF (Sender Policy Framework)?

SPF, or Sender Policy Framework, is a DNS record that lists the mail servers and IP addresses authorised to send email for your domain. When a receiving server gets a message, it looks at the envelope sender's domain, fetches that domain's SPF record, and checks whether the connecting server's IP address is on the approved list. If it is, the message passes SPF; if not, it fails.

An SPF record is a single TXT record in your DNS. Here is a realistic example:

• Type: TXT
• Host / Name: @ (the root of your domain)
• Value: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.24 -all

Reading that record from left to right: v=spf1 declares the SPF version; each include: delegates authorisation to another provider's SPF record (for example a hosted email service or a marketing platform); ip4: authorises a specific server IP such as your own mail relay; and the final qualifier tells receivers what to do with everything else.

SPF qualifiers explained

• -all (hard fail): reject anything not listed. This is the strict, recommended setting once you are confident every legitimate source is included.
• ~all (soft fail): treat unlisted sources with suspicion but still accept them, usually flagged. A safe interim setting during rollout.
• ?all (neutral): no policy — offers almost no protection.
• +all: authorises everyone. Never use this; it defeats the purpose.

SPF has two important limits. First, a domain may have only one SPF record, and it must resolve within ten DNS lookups — too many include: statements cause a PermError that breaks authentication. Second, SPF validates the envelope sender (the hidden Return-Path), not the visible From: address the recipient reads. It also breaks when a message is forwarded, because the forwarding server's IP is not on your list. These gaps are exactly why DKIM and DMARC are needed alongside it.

What is DKIM (DomainKeys Identified Mail)?

DKIM, or DomainKeys Identified Mail, is a cryptographic signature added to every outgoing message that lets the receiver confirm the email was genuinely authorised by your domain and was not altered in transit. Where SPF checks the sending IP, DKIM proves authenticity and integrity with public-key cryptography.

Here is how it works. Your mail server holds a private key. When it sends a message, it signs selected headers and the body, then attaches the signature in a DKIM-Signature header. You publish the matching public key as a DNS TXT record at a named location called a selector. The receiving server reads the signature, fetches the public key from your DNS, and verifies the signature. If the maths checks out, the message passed DKIM and has not been tampered with.

A DKIM DNS record looks like this:

• Type: TXT
• Host / Name: selector1._domainkey.yourcompany.com
• Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

The selector1 part is the selector name, which lets you run several keys at once (for example one for your mail platform and one for a newsletter tool) and rotate them safely. The p= value is the public key itself. Because forwarding does not change the signed content, DKIM survives message forwarding far better than SPF — one of the key reasons both standards are used together.

What is DMARC (Domain-based Message Authentication)?

DMARC, or Domain-based Message Authentication, Reporting and Conformance, is the policy layer that ties SPF and DKIM to the visible From: address, tells receivers what to do when checks fail, and sends you reports about who is using your domain. SPF and DKIM each verify a technical identifier, but neither guarantees that identifier matches the address the human actually sees. DMARC adds that crucial link, called alignment.

A message passes DMARC if it passes SPF or DKIM and the passing identifier's domain aligns with the From: domain. If a message fails, your DMARC policy instructs the receiver on how to handle it.

A DMARC record is one TXT record:

• Type: TXT
• Host / Name: _dmarc.yourcompany.com
• Value: v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s

The three DMARC policies

• p=none — monitor only. Nothing is blocked, but you receive reports. This is where every deployment should start so you can see your legitimate traffic before enforcing.
• p=quarantine — send failing messages to spam/junk. A safe middle step.
• p=reject — refuse failing messages outright. This is the goal state; it is what actually stops spoofing of your domain.

The rua address receives aggregate reports (daily XML summaries of all traffic claiming to be your domain), while ruf receives forensic reports (individual failure samples). The adkim and aspf tags control whether alignment is strict (s) or relaxed (r), and pct lets you apply the policy to a percentage of mail during a gradual rollout.

How SPF, DKIM and DMARC work together

The three standards are not alternatives — they are layers, and each covers the others' weaknesses. Think of it as a chain of trust:

1. SPF answers: is this server allowed to send for the domain?
2. DKIM answers: is this message genuinely signed by the domain and unaltered?
3. DMARC answers: does the verified identity match the address the reader sees, and what should happen if it does not?

When a receiving server accepts an email, it runs all three checks. SPF may fail because the message was forwarded, but DKIM still passes because the signature is intact — so DMARC alignment succeeds and the message is delivered. If a spoofer sends from an unauthorised server with no valid signature, SPF and DKIM both fail, alignment fails, and DMARC with p=reject blocks the message before it reaches the inbox. That combined coverage is why security frameworks and every major mailbox provider now expect all three to be configured.

As of 2024, Google and Yahoo require bulk senders to authenticate with SPF, DKIM and a valid DMARC policy, or their mail is throttled and rejected — making SPF DKIM DMARC a deliverability requirement, not just a security nicety.

Step-by-step: configuring SPF, DKIM and DMARC

Deploying these records is methodical work. Rushing to enforcement before your legitimate sources are covered is the most common way to accidentally block your own mail. Follow this order:

Step 1 — Inventory every sending source

List everything that sends email as your domain: your primary mail platform, your website contact and quote forms, CRM, invoicing software, newsletter tools, support desk and any server relays. Missing one source is the usual cause of legitimate mail failing after enforcement.

Step 2 — Publish SPF

Create a single SPF TXT record that includes every source from your inventory. Start with ~all (soft fail) while you validate, and keep the total DNS lookups under ten.

Step 3 — Enable DKIM on every platform

Turn on DKIM signing in each sending service. Each generates a key and gives you a selector record to publish in DNS. Verify each signature validates before moving on.

Step 4 — Start DMARC in monitoring mode

Publish a DMARC record with p=none and a valid rua address. Nothing is blocked yet, but aggregate reports begin arriving so you can see exactly which sources pass and fail alignment.

Step 5 — Read the reports and fix gaps

Aggregate reports arrive as XML; a DMARC report analyser makes them readable. Spend two to four weeks confirming every legitimate source aligns. Fix any that fail by correcting their SPF include or enabling DKIM.

Step 6 — Tighten to enforcement

Once reports are clean, move SPF to -all, then step DMARC from p=none to p=quarantine, and finally to p=reject. Many teams use pct= to enforce gradually — for example p=quarantine; pct=25 before going to 100 percent.

Understanding the reports

DMARC reporting is the feature that turns email authentication from a one-time setup into ongoing visibility. Aggregate (rua) reports tell you, per source IP, how many messages claimed to be your domain and whether they passed SPF, DKIM and alignment. This is how you discover a marketing tool nobody told IT about, or a criminal server trying to impersonate your brand. Forensic (ruf) reports provide redacted samples of individual failures for deeper investigation, though many providers limit them for privacy reasons. Reviewing these reports regularly is what keeps your policy accurate as your sending sources change over time.

Common mistakes to avoid

• Publishing two SPF records. A domain must have exactly one. Two records cause a permanent error and break SPF entirely — merge them into a single line.
• Exceeding the ten-lookup SPF limit. Too many include: entries trigger a PermError. Flatten or consolidate providers where possible.
• Jumping straight to p=reject. Without a monitoring phase you will block legitimate mail from a source you forgot. Always start at p=none.
• Forgetting a sending source. Invoicing, forms and newsletter tools are easy to miss and will fail once you enforce.
• Setting DMARC with no rua address. Without reports you are blind. Always include a monitored mailbox.
• Never rotating DKIM keys. Keys should be rotated periodically; selectors make this painless, so there is no excuse to keep a stale key forever.
• Leaving records unmonitored after setup. New tools, migrations and provider changes silently break alignment. Review reports on a schedule.

Summary table

Conclusion

SPF, DKIM and DMARC are no longer optional for any organisation that relies on email. SPF declares which servers may send for you, DKIM cryptographically proves each message is genuine and unaltered, and DMARC ties both to the address your recipients actually see while giving you a policy and full reporting. Deployed together and in the right order — monitor first, then enforce — they eliminate domain spoofing, protect your brand from phishing, and keep your legitimate mail landing in the inbox.

Correctly configuring these records, reading DMARC reports and moving safely to p=reject takes care and experience. As an IT infrastructure and corporate security provider in Antalya, our team helps businesses audit their DNS, cover every sending source, and reach full email authentication enforcement without disrupting day-to-day mail. Explore our corporate IT and security solutions to see how we secure business communication end to end. For the full technical specification of the policy layer, see the official DMARC standard (RFC 7489).