How to Set Up SPF, DKIM, and DMARC Records

Why email authentication records matter

Over 300 billion emails are sent every day, and nearly half is estimated to be spam or phishing attempts. Attackers routinely fake the From email address to impersonate legitimate companies or people - this technique is called email spoofing. Without proper protective mechanisms, anyone can send an email that looks like it comes from your domain, potentially deceiving your clients, partners, or employees. SPF, DKIM, and DMARC are three interrelated DNS records that together form an email authentication system and protect your domain from abuse.

Beyond spoofing protection, these records directly affect the delivery of your legitimate emails. Gmail, Outlook, and other major email providers are increasingly strict about authentication checks, so it's important to have professional email hosting with proper configuration - since February 2024, Gmail requires DKIM and DMARC for anyone sending more than 5,000 emails per day. Without properly configured records, your business emails can land in the spam folder or be rejected entirely.

SPF (Sender Policy Framework)

How SPF works

SPF is a DNS TXT record that defines which servers are authorized to send email on behalf of your domain. When a recipient's email server receives a message from your domain, it checks the SPF record in DNS to determine whether the sender's server is on the authorized list. If the server isn't on the list, the email can be flagged as suspicious or rejected. SPF checks the envelope sender address (MAIL FROM), not the From header the user sees, which is an important distinction for understanding how SPF works with DMARC.

Creating an SPF record

The SPF record is added as a TXT record in your domain's DNS. The basic format starts with v=spf1 indicating the version, followed by mechanisms that define authorized senders, and ends with a qualifier that determines what to do with unauthorized senders. For example, for a domain using BeoHosting for email and Google Workspace for business email, the SPF record would look like this: v=spf1 include:_spf.beohosting.com include:_spf.google.com -all. The include mechanism pulls in SPF records of another domain, and -all at the end means all other servers are not authorized and email should be rejected.

Common SPF mistakes

The most common mistake is exceeding the 10 DNS lookup limit. Every include, a, and mx mechanism requires a DNS lookup, and if you have too many, SPF validation automatically fails. The solution is to use ip4 and ip6 mechanisms that don't consume lookups, or to consolidate includes. Another common mistake is using tilde instead of minus at the end - ~all is a soft fail that only marks email as suspicious instead of rejecting it, while -all is a hard fail that's safer. The third mistake is forgetting to add all services that send email on your behalf - transactional emails, newsletter platforms, CRM systems, and helpdesk tools.

DKIM (DomainKeys Identified Mail)

How DKIM works

DKIM uses public-key cryptography to sign outgoing emails. Your email server adds a digital signature in the header of every message using a private key known only to your server. The recipient's server finds the public key in your domain's DNS and uses it to verify the signature. If the signature matches, it proves two things: the email was actually sent from a server controlled by the domain owner, and the email content wasn't changed in transit. Unlike SPF which only checks the sender's IP address, DKIM confirms the integrity of the message itself.

Generating DKIM keys

DKIM keys are generated as a private and public key pair. The private key is installed on the email server and used for signing messages. The public key is published as a DNS TXT record on a specific subdomain in the format selector._domainkey.yourdomain.com. The selector is an arbitrary string that identifies the key, for example default or google. The recommended minimum key length is 2048 bits - shorter keys of 1024 bits are considered insecure. Most hosting providers and email services automatically generate DKIM keys and give you only the DNS record to add.

Setting up DKIM

To set up DKIM on BeoHosting, access cPanel and find the email authentication section where DKIM is usually already activated. For Google Workspace, go to Admin Console, then Apps, Gmail, Authenticate Email, and generate the DKIM key. Google gives you a TXT record to add to DNS. For Microsoft 365, the process is similar - in the Exchange Admin Center you enable DKIM for each domain and add two CNAME records to DNS. After adding DNS records, wait up to 48 hours for DNS propagation, though 1-2 hours is usually enough.

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

How DMARC works

DMARC ties SPF and DKIM into a unified system and defines what the recipient's server should do with an email that fails authentication. DMARC introduces the concept of alignment - it checks whether the domain in the From header (which the user sees) matches the domain that passed the SPF or DKIM check. This is key because SPF and DKIM by themselves don't protect the From header that users actually see. DMARC also introduces a reporting system that sends you daily reports about who sends email from your domain and whether they pass authentication.

Creating a DMARC record

The DMARC record is added as a TXT record on the _dmarc.yourdomain.com subdomain. The basic record looks like this: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The v tag indicates the version, p defines the policy (none, quarantine, or reject), and rua is the email address for receiving aggregated reports. We recommend a gradual approach: start with p=none to just track who sends email from your domain without blocking, after analyzing reports move to p=quarantine so suspicious emails go to spam, and finally enable p=reject to completely reject unauthorized emails.

DMARC policies

The none policy is a monitoring mode that doesn't affect email delivery but sends you reports. Use it for the first 2-4 weeks to identify all legitimate services sending email from your domain and add them to SPF and DKIM configuration. The quarantine policy instructs the recipient's server to put suspicious emails in the spam folder - this is a good middle step that protects recipients but doesn't fully block emails in case of configuration errors. The reject policy is the strictest and fully rejects emails that don't pass authentication - enable it only when you're sure all legitimate sources are properly configured.

Analyzing DMARC reports

DMARC aggregated reports arrive in XML format and contain information about IP addresses sending email from your domain, whether they passed SPF and DKIM checks, and the percentage of emails passing authentication. Raw XML reports are hard to read, so we recommend using free tools like DMARC Analyzer, dmarcian, or Postmark DMARC tool that visualize the data and simplify analysis. Regular report analysis reveals unauthorized use of your domain and helps optimize configuration.

Testing the configuration

Online testing tools

After setting up records, be sure to test the configuration. MXToolbox is a comprehensive tool that checks SPF, DKIM, and DMARC records and shows detailed results with error explanations. Mail-tester.com rates overall email configuration on a scale from 1 to 10 - send a test email to a generated address and you'll get a detailed report. Google Postmaster Tools shows how Gmail sees your emails and identifies authentication problems. For DKIM specifically, use the DKIMCore tool to verify DNS records or send an email to check-auth@verifier.port25.com for automatic checking.

Command-line checking

For technical users, DNS records can be checked directly from a terminal. The command dig TXT yourdomain.com checks the SPF record. For DKIM use dig TXT selector._domainkey.yourdomain.com where selector is your DKIM selector. For DMARC use dig TXT _dmarc.yourdomain.com. On Windows use nslookup with type TXT. These commands show actual DNS values and help identify problems with propagation or record formatting.

Troubleshooting common issues

• Email goes to spam: Check whether SPF, DKIM, and DMARC all pass - use header analysis in the received email to see authentication results.
• SPF PermerError: Too many DNS lookups - consolidate include mechanisms or use IP addresses directly.
• DKIM fail: Check whether the public key is properly published in DNS and whether the selector in DNS matches the selector the email server uses.
• DMARC alignment fail: The From domain doesn't match the domain in the SPF or DKIM check - common with third-party email services.
• Newsletter bouncing: Add your newsletter service (Mailchimp, SendinBlue) to the SPF record and enable DKIM signing through their dashboard.
• Transactional emails rejected: SaaS platforms sending email on your behalf must be included in SPF and have DKIM signing.

Conclusion

Properly configuring SPF, DKIM, and DMARC records is now mandatory for every domain that sends emails. These records protect your brand from spoofing, improve delivery of legitimate emails, and provide insight into who's sending email from your domain. Start with SPF, add DKIM, then enable DMARC in monitoring mode and gradually tighten the policy. At BeoHosting we automatically configure SPF and DKIM for all hosting accounts and provide technical support for setting up DMARC with the goal that your emails always land in the inbox rather than the spam folder.