SPF, DKIM, and DMARC Explained: Email Authentication in Plain Language

Published

Without authentication, anyone can pretend to be you

Email was designed in a era when trust was assumed. The protocol doesn’t inherently verify that a message claiming to be from [email protected] actually came from you. Anyone can set up a mail server, put your address in the “from” field, and send mail as if they were you. That’s how phishing works.

Email authentication fixes this. It’s a set of technical records you publish for your domain that tell mailbox providers how to verify that mail claiming to be from you actually came from you. Without these records, mailbox providers have to guess — and many guess “spam” by default.

What SPF, DKIM, and DMARC actually do

The three work together as a layered defense. Each handles a different part of the verification:

SPF (Sender Policy Framework)

SPF is a list of mail servers authorized to send email on behalf of your domain. You publish this list as a DNS record (a text entry in your domain’s settings). When a mailbox provider receives an email claiming to be from your domain, it checks your SPF record to see if the sending server is on the list. If it is, the email passes. If it’s not, the email is suspicious.

Think of it as: a guest list at the door. The bouncer checks the server’s ID against the list. If you’re on the list, you’re in. If not, you’re turned away.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to each email you send. The signature is generated by your sending server using a private key that only you have. The mailbox provider verifies the signature using a public key that you publish in your DNS records. If the signature matches, the email hasn’t been tampered with in transit and genuinely came from your domain.

Think of it as: a wax seal on an envelope. The seal proves the letter wasn’t opened or forged after it left your hands. Only you have the seal; anyone can check it against your published reference.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC ties SPF and DKIM together and tells mailbox providers what to do if an email fails both checks. You publish a DMARC policy that says one of three things: “do nothing” (monitor only), “send to spam” (quarantine), or “reject entirely.” DMARC also sends you reports about which emails passed and failed, so you can see if someone is trying to spoof your domain.

Think of it as: the instruction manual that goes with the guest list and the wax seal. It tells the bouncer what to do with someone who fails both checks — let them in anyway, send them to the back of the line, or throw them out.

Why it matters

  • Mailbox providers require it. Gmail and Yahoo introduced mandatory authentication requirements in 2024 for bulk senders. If you send more than 5,000 emails per day and don’t have authentication set up, your emails will be rejected or sent to spam.
  • It prevents spoofing. Without authentication, scammers can send phishing emails that appear to come from your domain. That damages your brand and can harm your customers.
  • It improves deliverability. Authenticated emails are more likely to reach the inbox. Unauthenticated emails are more likely to be filtered or rejected.
  • DMARC reports give you visibility. The reports show you exactly which sources are sending mail as your domain — including legitimate sources you may have forgotten to authorize and fraudulent sources you need to block.
  • It’s becoming the standard. Even for small senders, authentication is increasingly expected. Setting it up now prevents problems later.

How to set up email authentication

  1. Set up SPF. Work with your ESP to identify which mail servers send on your behalf. Create an SPF DNS record that lists those servers. Your ESP will provide the exact record to publish.
  2. Set up DKIM. Your ESP generates a key pair and gives you the public key to publish as a DNS record. Once published, your ESP signs each outgoing email with the private key.
  3. Set up DMARC. Start with a monitoring-only policy (p=none) so you can receive reports without affecting delivery. Review the reports for a few weeks to confirm all legitimate sending sources are covered by SPF and DKIM. Then gradually tighten the policy to quarantine and eventually reject.
  4. Publish records for every sending domain. If you send from [email protected] and [email protected], both subdomains need records. Even domains you don’t send from should have DMARC reject policies to prevent spoofing.
  5. Test after setup. Send a test email to a service that checks authentication (many free tools exist) and confirm SPF, DKIM, and DMARC all pass. Then send to your own inbox and check the authentication headers.
  6. Review DMARC reports regularly. The reports show you sending sources, authentication results, and potential spoofing attempts. Check them at least monthly.

Common mistakes

  • SPF only, no DKIM or DMARC. SPF alone is a partial solution. Without DKIM, emails can be tampered with in transit. Without DMARC, mailbox providers don’t know what to do with failures.
  • DMARC set to reject immediately. If you start with p=reject before confirming all legitimate sources are authenticated, you’ll block your own emails. Always start with p=none and tighten gradually.
  • Forgetting third-party senders. If your billing software, support desk, or marketing tool sends mail as your domain, they need to be in your SPF record and DKIM-signed. Forgetting them causes legitimate emails to fail.
  • Not testing. Setting up records without verifying them is like installing a lock without checking that it closes. Always test after setup.
  • Ignoring DMARC reports. The reports are the whole point of DMARC monitoring. If you don’t read them, you won’t know about spoofing attempts or misconfigured senders.

How authentication relates to Temway

Temway is a builder and exporter — it produces the HTML for your emails. Authentication is set up at the domain and ESP level, not in the email builder. So the workflow is: build your email in Temway, export the HTML or push it to your ESP, and your ESP handles the signing and sending with your authenticated domain.

If you haven’t set up SPF, DKIM, and DMARC yet, contact your ESP’s support — they’ll provide the exact DNS records to publish with your domain registrar. Most ESPs have step-by-step guides for this setup. Once it’s done, you don’t need to think about it again for each email — authentication happens automatically on every send.

Where to go next