Where should SPF, DKIM, and DMARC records be placed for email authentication?
Michael Ko
Co-founder & CEO, Suped
Published 26 May 2025
Updated 19 Aug 2025
10 min read
Understanding where to place your SPF, DKIM, and DMARC records is fundamental for ensuring your emails are authenticated and delivered reliably. These records are critical for verifying your domain's identity, preventing spoofing, and maintaining a healthy sender reputation. Many people wonder if these records should reside on their primary domain or if specific mailing subdomains require separate configurations.
Proper placement impacts how receiving mail servers, like Google and Microsoft, interpret your emails. Misconfigured records can lead to emails landing in spam folders or being rejected outright, which can severely impact your communication efforts. The key lies in understanding that these are DNS records, meaning they are published in your domain's Domain Name System.
This guide will walk you through the correct placement for each record type, clarifying how they interact with your primary domain and any subdomains you use for sending email.
SPF (Sender Policy Framework) records are designed to prevent email spoofing by specifying which mail servers are authorized to send email on behalf of your domain. When a recipient's mail server receives an email, it checks the SPF record published in your DNS to verify the sender's IP address. If the sending IP is not listed, the email might be flagged as spam or rejected. The SPF record is a TXT record.
You should place your SPF record at the root of the domain (or subdomain) that is listed in the Return-Path (also known as MAIL FROM) header of your outgoing emails. For most senders, this will be your primary sending domain. For example, if your emails appear to come from yourdomain.com, the SPF record should be published directly for yourdomain.com. It's crucial to ensure that all legitimate sending sources, including third-party email service providers (ESPs), are included in your SPF record to prevent legitimate emails from being marked as spam. You can learn more about best practices for SPF records in our other resources.
If you use a subdomain specifically for sending emails, such as mail.yourdomain.com, and this subdomain is used in the Return-Path header, then a separate SPF record should be created for that subdomain. However, SPF records should not use CNAME records due to DNS lookup limits, as detailed in best practices for SPF records. One common mistake is having multiple SPF records at the same domain level, which can invalidate all of them. Always consolidate all authorized senders into a single SPF record per domain or subdomain.
Example SPF Record
yourdomain.com. IN TXT "v=spf1 include:_spf.example.com include:spf.another.com -all"
DKIM record placement
DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails, allowing receiving servers to verify that the email was sent by an authorized sender and has not been tampered with in transit. This signature is generated using a private key on the sending server and is verified using a public key published in your DNS. Like SPF, a DKIM record is also a TXT record.
The DKIM record is placed on a specific subdomain prefixed with a selector and _domainkey. For instance, if your selector is s1 and your domain is yourdomain.com, the record would typically be found at s1._domainkey.yourdomain.com. The selector allows you to have multiple DKIM keys for the same domain, which is useful when using multiple sending services or rotating keys for security. Most email service providers will give you the exact DKIM record to add to your DNS.
If you are sending emails from a subdomain, such as marketing.yourdomain.com, and the d=domain in your DKIM signature is marketing.yourdomain.com, then the DKIM record should be published for that specific subdomain. This is crucial for proper DKIM alignment with your DMARC policy. You can find more information about DKIM selectors and their use in our guides.
Example DKIM Record
s1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDzN9+..."
DMARC record placement
DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds upon SPF and DKIM. It allows domain owners to specify how receiving mail servers should handle emails that fail SPF or DKIM checks, and it provides a mechanism for receiving reports on authentication failures. This gives you visibility into email streams and helps identify potential spoofing attempts. A DMARC record is also a TXT record.
Unlike SPF and DKIM which can be domain or subdomain specific depending on the sending pattern, the DMARC record for a given domain is always placed at the _dmarc subdomain of the organizational domain. For example, for yourdomain.com, the DMARC record would be at _dmarc.yourdomain.com. Even if you send emails from subdomains, the DMARC policy for those subdomains can be inherited from the organizational domain's DMARC record, unless a specific DMARC record is published for the subdomain using the sp tag or a separate _dmarc record for that subdomain. You can use our DMARC record generator for easy setup.
A crucial aspect of DMARC is the p= policy tag, which dictates the action taken for non-aligned emails (none, quarantine, or reject). Initially, it is recommended to start with p=none to collect reports and monitor email traffic without impacting deliverability. Gradually, as you confirm your legitimate email sources are authenticated, you can transition to quarantine or reject. More details on DMARC policy examples can be found in our guide to DMARC policies.
Example DMARC Record
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1"
Subdomains and third-party senders
When you use third-party email services (e.g., marketing platforms, transactional email senders), the placement of SPF and DKIM records becomes particularly important. These services send emails on your behalf, so your DNS records must authorize their sending infrastructure. Generally, the third-party service will provide you with specific SPF include mechanisms and DKIM TXT records that you need to add to your domain's DNS. This setup allows receiving mail servers to authenticate emails sent via these services as genuinely coming from your domain. For further detail, you can check out the Cloudflare article on DMARC, DKIM, and SPF.
For subdomains used for specific sending purposes, like news.yourdomain.com for newsletters, you should create dedicated SPF and DKIM records for that subdomain if the Return-Path or d=domain (DKIM) is set to the subdomain. This granular approach helps isolate the reputation of your main domain from any issues that might arise with a specific sending stream. However, the DMARC record generally stays at the organizational domain level, providing an overarching policy for both the main domain and its subdomains, unless explicitly overridden.
It is important to differentiate between the From: header (what users see) and the Return-Path (used by SPF). Ensuring proper alignment between these domains is critical for DMARC to pass. If SPF or DKIM fail alignment checks, the DMARC policy will be applied. For more insights into setting up email authentication, a Mailgun blog post on email authentication provides further details.
Primary domain records
This is your main domain, e.g., yourdomain.com. Typically, you'd place the DMARC record here, along with SPF and DKIM records if all email originates from this domain.
DMARC: Always at _dmarc.yourdomain.com.
SPF: At the root domain if Return-Path uses yourdomain.com.
DKIM: At selector._domainkey.yourdomain.com.
Sending subdomain records
If you send email from a subdomain like mail.yourdomain.com, you'll need specific records for that subdomain.
DMARC: Inherited from primary domain unless explicit _dmarc.subdomain.yourdomain.com is set.
SPF: At mail.yourdomain.com if Return-Path uses the subdomain.
DKIM: At selector._domainkey.mail.yourdomain.com if d=domain uses the subdomain.
Importance of proper configuration and monitoring
Implementing SPF, DKIM, and DMARC correctly requires careful attention to detail. A single misconfiguration can lead to deliverability issues, including emails being sent to spam or even being blocked entirely. It's not just about adding the records, but ensuring they are correctly formatted and updated to reflect all your sending sources. This includes both your internal mail servers and any third-party services.
Regularly reviewing your DNS records for these authentication protocols is a critical best practice. Changes to your email sending infrastructure, new marketing platforms, or even updates from existing vendors might require adjustments to your SPF and DKIM records. Neglecting these updates can lead to valid emails failing authentication, negatively impacting your sender reputation, and potentially landing your domain on an email blacklist (or blocklist).
Tools that provide DMARC reports can be invaluable for monitoring your email authentication status and identifying any issues. These reports show you which emails are passing or failing SPF and DKIM checks and can help pinpoint misconfigurations or unauthorized sending. Consistent monitoring is key to maintaining high email deliverability and ensuring your messages reach the inbox.
Tips for managing your records
Single SPF Record: Always combine all SPF include mechanisms into one TXT record per domain to avoid errors.
DNS Lookup Limit: Be mindful of the 10-DNS-lookup limit for SPF records to prevent PermError failures.
DMARC Reporting: Utilize DMARC aggregate reports (rua) for visibility into your domain's email traffic and authentication status.
Subdomain Policy: Decide whether subdomains should inherit the main DMARC policy or have their own specific records.
Views from the trenches
Best practices
Ensure that all legitimate sending services are explicitly included in your SPF record, whether it's on your main domain or a specific subdomain.
Confirm that DKIM records are correctly published for each sending domain or subdomain, aligning the d=domain with your email's From: header.
Implement DMARC at the organizational domain level to establish a robust policy for all email from your brand, and use the 'rua' tag for critical reporting.
Common pitfalls
Creating multiple SPF TXT records for a single domain, which invalidates them all and leads to authentication failures.
Forgetting to update SPF or DKIM records when switching email service providers or adding new sending sources.
Not setting up DMARC reporting, leaving you blind to spoofing attempts and legitimate email authentication issues.
Expert tips
Consider using different subdomains for different types of email (e.g., marketing, transactional) to better manage sender reputation.
Regularly review DMARC reports to identify potential issues and ensure ongoing compliance.
Start with a DMARC policy of 'p=none' to gather data before enforcing stricter policies like 'quarantine' or 'reject'.
Marketer view
Marketer from Email Geeks says some vendors don't require SPF or DKIM records to be set directly on your mailing subdomain because they configure the sender and return-path domains themselves, thereby handling their own authentication policies.
2024-01-24 - Email Geeks
Marketer view
Marketer from Email Geeks says a common issue in larger organizations is a lack of clear ownership for email authentication records, leading to misconfigurations and deliverability problems.
2024-02-15 - Email Geeks
Ensuring successful email authentication
Correctly placing your SPF, DKIM, and DMARC records is a cornerstone of effective email deliverability and security. While SPF and DKIM records are directly tied to the specific domain or subdomain used in the email's Return-Path and d=domain values, the DMARC record typically resides at the organizational domain level, providing policy enforcement and reporting for your entire domain ecosystem. Whether you use your primary domain or dedicated subdomains for sending, each must have its authentication records properly published in DNS.
By following these guidelines and regularly monitoring your authentication results, you can significantly improve your email deliverability, protect your brand reputation, and mitigate the risk of phishing and spoofing attacks. Understanding how these standards work together is essential for any sender.
Google and 
Microsoft, interpret your emails. Misconfigured records can lead to emails landing in spam folders or being rejected outright, which can severely impact your communication efforts. The key lies in understanding that these are DNS records, meaning they are published in your domain's Domain Name System.
