Your business emails are landing in recipients' spam folders. Or Google is rejecting them outright. The culprit is almost always missing or misconfigured SPF, DKIM, or DMARC records. These three DNS records prove to receiving mail servers that your emails are legitimate, together they form the foundation of modern email authentication.
Email was designed in the 1970s with no authentication. Any server can send a message claiming to be from any address. Spammers and phishers exploit this constantly, sending emails that appear to come from legitimate domains they don't control. SPF, DKIM, and DMARC were developed over the past two decades to fix this, using DNS records to let domain owners declare who is authorised to send email on their behalf.
When all three are configured correctly, receiving servers can verify that an email genuinely came from where it claims, hasn't been tampered with in transit, and was sent by an authorised server. Emails that pass all three checks land in inboxes. Emails that fail get quarantined or rejected.
SPF is a TXT record at your domain's root that lists the mail servers authorised to send email on behalf of your domain. When a receiving server gets an email claiming to be from you@yourdomain.com, it checks the SPF record to see if the sending server's IP is on the authorised list.
A basic SPF record for Google Workspace:
Breaking this down: v=spf1 identifies it as an SPF record; include:_spf.google.com authorises Google's sending servers; ~all means all other sources should be treated as a soft fail (suspicious, but not automatically rejected).
Using -all instead enforces a hard fail, any server not explicitly listed is rejected. Start with ~all until you're confident all your legitimate sending sources are included, then tighten to -all.
Common SPF pitfall: you can only have one SPF record per domain. If you use multiple services that provide SPF records (e.g. Google Workspace plus a transactional email service like SendGrid), combine them into a single record:
DKIM adds a cryptographic signature to outgoing emails. Your mail server signs each message with a private key. A corresponding public key is published in your DNS as a TXT record at a "selector" subdomain. Receiving servers use the public key to verify the signature and confirm the email hasn't been altered in transit.
The DKIM TXT record is published at a subdomain in the format selector._domainkey.yourdomain.com. The selector is a label your email provider chooses (often "google", "mail", "s1", etc.). Example for Google Workspace:
Your email provider generates the DKIM keys and gives you the exact record to add. You don't need to understand the key contents, just copy and paste the record value exactly as provided.
Why DKIM matters: SPF only checks that the sending server is authorised. DKIM proves the email content hasn't been tampered with and links the message to your domain cryptographically. Together they're significantly stronger than either alone.
DMARC builds on SPF and DKIM. It tells receiving servers what policy to enforce when an email fails SPF or DKIM: do nothing (p=none), quarantine it (p=quarantine), or reject it outright (p=reject). It also enables reporting, so receiving servers can send you aggregate reports showing what's being sent in your domain's name.
DMARC requires that the domain in the email's From header aligns with either the SPF-verified domain or the DKIM-signed domain. This alignment check prevents spammers from using a legitimate SPF-passing server while still spoofing the From address.
A starter DMARC record (monitor-only mode):
With p=none, DMARC generates reports without affecting delivery. This lets you see what's sending email in your domain's name before you enforce anything. After reviewing reports and ensuring all legitimate senders pass SPF and DKIM, move to p=quarantine, then eventually p=reject.
In February 2024, Google and Yahoo updated their sender requirements. Any sender sending more than 5,000 emails per day to Gmail or Yahoo addresses must have SPF, DKIM, and DMARC configured. Bulk senders must have DMARC with at least p=none.
Even for smaller senders, Google recommends these records for all domains using custom email. Missing authentication is one of the most common reasons emails land in spam or get bounced. Every business using a custom domain for email should have all three configured.
Use our dedicated tools to check each record for your domain: SPF Checker, DKIM Checker, and DMARC Checker. Each tool validates the record and flags any issues clearly.
From the command line:
# Check SPF dig yourdomain.com TXT +short # Check DMARC dig _dmarc.yourdomain.com TXT +short # Check DKIM (replace 'google' with your selector) dig google._domainkey.yourdomain.com TXT +short
To verify your records are correctly published before sending, run each checker above and confirm all three pass. If any record is missing or misconfigured, the checker will show exactly what needs to be changed.
Set up SPF first, then DKIM, then DMARC. SPF and DKIM must be working correctly before you add a DMARC record, otherwise DMARC will flag all your legitimate email as failing. Start DMARC at p=none to monitor without affecting delivery, review the reports over 2 to 4 weeks, then tighten the policy once you're confident everything legitimate is passing.
HostBible professional email includes SPF, DKIM, and DMARC setup as part of onboarding. Your emails land in inboxes, not spam folders, from day one.
View Professional Email