If your emails are landing in spam, or you've heard that you need to "set up authentication records" but aren't sure what that means, this guide is for you. SPF, DKIM, and DMARC are three DNS-based standards that prove to the internet that your emails are legitimate. Together, they form the foundation of modern email deliverability. Understanding these standards doesn't require a computer science degree. By the end of this guide, you'll know what each one does, why it matters, and how to verify yours are working correctly. ## The Problem These Standards Solve Email was invented in the 1970s without any concept of authentication. Anyone could claim to be sending from any address. Spammers and phishers exploited this for decades — sending emails that appeared to come from your bank, your boss, or a trusted vendor while actually originating from a server halfway around the world. SPF, DKIM, and DMARC were developed to solve this problem by giving receiving mail servers cryptographic and policy-based tools to verify the identity of senders. ## SPF — Sender Policy Framework SPF is the simplest of the three. It's a DNS TXT record on your domain that lists the IP addresses and mail servers authorized to send email on your behalf. When a receiving mail server gets an email claiming to be from [email protected], it looks up your domain's SPF record and checks whether the sending server's IP address is on the approved list. If it is, the check passes. If it isn't, the server can treat the email with suspicion or reject it outright. **Example SPF record:** ``` v=spf1 mx a include:_spf.bytesmtp.com ~all ``` Breaking this down: - `v=spf1` — identifies this as an SPF record - `mx` — authorizes the servers listed in your MX records - `a` — authorizes the IP address of your domain's A record - `include:_spf.bytesmtp.com` — includes ByteSMTP's authorized sending IPs - `~all` — any server not listed results in a soft fail (treated with suspicion but not outright rejected) Using `-all` instead of `~all` makes it a hard fail, which is stricter but can cause problems if your record is incomplete. **Common SPF mistakes:** - Having more than one SPF record (only one is allowed per domain) - Forgetting to include third-party senders like marketing platforms - Using `-all` before you're certain all senders are listed ## DKIM — DomainKeys Identified Mail DKIM adds a cryptographic signature to every email you send. Think of it like a wax seal on a letter — it proves the message came from you and hasn't been altered in transit. When you set up DKIM, your mail server generates a pair of cryptographic keys. The private key stays on your mail server and is used to sign outgoing messages. The public key is published as a DNS TXT record on your domain. When a receiving server gets your email, it retrieves your public key and uses it to verify the signature. If the signature is valid, the email is authentic. **Example DKIM DNS record name:** ``` mail._domainkey.yourdomain.com ``` **Example DKIM record value:** ``` v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4... ``` The long string of characters is your public key. ByteSMTP generates this automatically when you add your domain — you just copy and paste the record into your DNS. **Why DKIM matters beyond spam filtering:** Because DKIM signs the content of the message, it also protects against email tampering. If someone intercepts your email and modifies it, the DKIM signature will fail on the receiving end, alerting the server that something is wrong. ## DMARC — Domain-based Message Authentication, Reporting & Conformance DMARC is the policy layer that ties SPF and DKIM together. It tells receiving servers what to do when authentication fails, and it provides a reporting mechanism so you can see who is sending email using your domain. **Example DMARC record:** ``` v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100 ``` Breaking this down: - `v=DMARC1` — identifies this as a DMARC record - `p=quarantine` — emails failing authentication go to spam (options: none, quarantine, reject) - `rua=mailto:...` — where to send aggregate reports - `pct=100` — apply the policy to 100% of failing emails **The three DMARC policy levels:** *p=none* — Monitor only. Emails still deliver normally, but you receive reports showing what's passing and failing. This is the right starting point while you're getting authentication configured. *p=quarantine* — Failed emails go to spam. Use this once your SPF and DKIM are fully working and the reports show clean results. *p=reject* — Failed emails are refused outright. This is the gold standard for protecting your domain from being spoofed, but only move to reject after extensive monitoring. ## How They Work Together For a DMARC policy to protect you, at least one of SPF or DKIM must "align" — meaning the authenticated domain matches the From header domain. This is what makes DMARC powerful. A spammer might be able to pass SPF from their own domain, but they can't make it align with yours. ## Checking Your Authentication Status Several free tools let you verify your records are correct: - **MXToolbox** (mxtoolbox.com) — check SPF, DKIM, and DMARC records - **Mail Tester** (mail-tester.com) — send a test email and get a deliverability score - **ByteSMTP Dashboard** — built-in authentication diagnostics for all your domains ## What Happens Without These Records Without SPF and DKIM, your emails are more likely to be flagged as spam by Gmail, Outlook, and other major providers. Since 2024, Google and Yahoo have required bulk senders to have SPF, DKIM, and DMARC in place — and they've signaled these requirements will extend to all senders over time. Without DMARC, anyone can forge your domain in the From header and send phishing emails that appear to come from you. This can damage your brand reputation and expose your clients to fraud. ## The Simple Version Set up SPF so servers know who's allowed to send for your domain. Set up DKIM so every message is cryptographically signed. Set up DMARC starting at p=none, review the reports for a few weeks, then move to quarantine and eventually reject. ByteSMTP handles all of this automatically when you add a domain — the records are generated for you and the private DKIM key is managed on the server side.