Emails Landing in Spam? SPF, DKIM, and DMARC Explained and Set Up

Your email doesn't reach someone's inbox because you sent it. It arrives there because the receiving mail server decided to let it through. That decision rests on three DNS records most businesses never set up: SPF, DKIM, and DMARC. Without them, your transactional confirmations, newsletter campaigns, and contact form notifications look indistinguishable from spoofing attempts. The result: spam folder, or silent rejection.

This guide explains what each record does, how they work together, what Google and Yahoo now require from senders, and how to make your website's form emails reliably deliverable.

Why Emails Land in Spam

Mail servers don't trust the "From" address you display. Anyone can compose an email claiming to be from your domain. Receiving servers therefore look for cryptographic evidence that you authorized the sending. That evidence lives in your domain's DNS as text (TXT) records.

When those records are missing or misconfigured, servers either flag the message as suspicious or drop it outright. For small and medium-sized businesses, the gap often goes unnoticed: form submissions disappear, newsletters go unread, and transactional emails never arrive.

Three standards address this: SPF, DKIM, and DMARC. They cover different parts of the trust problem and work best when all three are in place.

SPF: Which Servers Are Allowed to Send Your Email

SPF (Sender Policy Framework) is a DNS record that lists the IP addresses and services authorized to send email from your domain. When a receiving mail server processes a message claiming to come from yourcompany.com, it checks that domain's SPF record. If the sending IP isn't on the authorized list, the check fails.

An SPF record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

v=spf1 identifies this as an SPF record. Each include: reference authorizes a sending service, so include:_spf.google.com covers Google Workspace and include:sendgrid.net covers SendGrid if you use it for newsletters. The -all at the end instructs receiving servers to reject all other senders, a hard-fail policy.

If you use multiple services to send email on behalf of your domain, each one needs to appear in the record. Missing a single service is enough to cause deliverability failures for messages from that service. One technical constraint: SPF allows only one TXT record per domain, and the chain of includes is limited to ten DNS lookups. With many sending services, this limit becomes relevant and may require consolidating records.

DKIM: The Cryptographic Signature

DKIM (DomainKeys Identified Mail) verifies the message itself rather than the sending server. Your mail server attaches a digital signature to each outgoing email using a private cryptographic key. The receiving server then retrieves the corresponding public key from your DNS and checks the signature.

If the signature matches, two things are confirmed: the message originated from a server holding the correct private key, and the content wasn't modified in transit. This addresses man-in-the-middle interception and forged message bodies.

DKIM is published as a TXT or CNAME record in your DNS, structured like this:

default._domainkey.yourcompany.com TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

The long p= string is the public key. Your email provider generates the key pair and gives you the DNS record to publish. Google Workspace, Microsoft 365, and most email platforms include DKIM setup instructions in their administrator documentation. The private key stays on the sending server and never appears in DNS.

DMARC: The Policy Layer

SPF verifies the sending server. DKIM verifies the message content. DMARC (Domain-based Message Authentication, Reporting and Conformance) ties them together and tells receiving servers what to do when a check fails.

DMARC introduces two concepts that SPF and DKIM alone cannot provide. The first is alignment: the domain in the visible "From" header must match the domain verified by SPF or DKIM. Without alignment, a sender could pass SPF on a background domain while displaying your domain in the "From" field. DMARC closes that gap.

The second is policy, which tells receivers how to handle failing messages:

• p=none: take no enforcement action, but send reports to the address you specify.
• p=quarantine: route failing messages to spam.
• p=reject: block failing messages entirely.

A DMARC record looks like this:

_dmarc.yourcompany.com TXT "v=DMARC1; p=none; rua=mailto:[email protected];"

The rua= address receives aggregate reports: daily XML files summarizing which servers sent on your behalf and whether SPF and DKIM passed. Reading these reports before moving to a stricter policy is what prevents you from accidentally blocking legitimate email flows you hadn't accounted for.

Which DMARC Policy Is Right for You?

Moving directly to p=reject before your SPF and DKIM are fully configured is a reliable way to block legitimate email. The standard progression is to set SPF and DKIM first, add DMARC at p=none, read the reports, and only then escalate the policy. The table below maps each stage to its purpose and the signal that tells you to move forward:

During the p=none phase, sign up for a DMARC reporting tool. Services such as dmarcian and DMARC Analyzer parse the raw XML aggregate reports into readable dashboards that show which sending services are passing and which are failing. Without a reporting tool, the XML files are difficult to interpret manually and you're likely to miss edge cases before escalating your policy.

What Google and Yahoo Now Require from Bulk Senders

Since February 2024, Google requires senders who send 5,000 or more messages per day to Gmail addresses to implement specific authentication measures (source: Google Email Sender Guidelines, published January 2024). These requirements include a valid SPF or DKIM record for the sending domain and a DMARC policy of p=none or stricter. Marketing and subscription messages must also include a one-click unsubscribe option that processes requests within two days.

Yahoo announced matching requirements, coordinated with Google's rollout. For senders below the 5,000-per-day threshold, both providers still use authentication signals as ranking factors in spam filtering. The practical implication is the same regardless of volume: having all three records in place is now a baseline expectation, not an optional step.

For businesses running email marketing campaigns, these requirements affect deliverability with other enterprise inbox providers as well. Microsoft, Apple, and most major mail services now treat the absence of SPF, DKIM, and DMARC as a negative trust signal, regardless of whether you send in bulk.

Making Website Form Emails Deliverable

When a visitor submits a contact form on your website, the notification email doesn't come from your own mail server. It comes from the platform or service hosting the form, using that platform's sending infrastructure.

For businesses with a Webflow website, form submission notifications originate from Webflow's sending servers by default. Your SPF record, configured for your own mail provider, doesn't cover these notifications automatically. The practical result: form notifications can land in spam even when your other business email is fully authenticated.

Three approaches address this:

• Transactional email service: Connect a service such as Postmark, Mailgun, or SendGrid to your domain. You publish their SPF and DKIM records in your DNS and they send on your behalf with full alignment. This gives you authentication, delivery logs, and bounce tracking for every notification.
• SMTP relay through your existing provider: Some platforms allow you to specify an outgoing SMTP server. Routing through your existing mail provider (Google Workspace or Microsoft 365) means those servers are already in your SPF record and DKIM is already configured. Alignment is maintained automatically.
• Platform defaults with Reply-To: Leave form notifications going out from the platform's own sending domain, with a Reply-To header pointing to your address. Authentication passes on the platform's domain, not yours. This is acceptable for simple notifications, but not for marketing emails or any message where your domain's reputation affects how it's received.

The same logic applies regardless of which website platform you use. Each additional service that sends email on behalf of your domain needs to appear in your SPF record and have DKIM configured. For an overview of how Webflow handles forms and third-party integrations, the platform's official documentation covers the available connection options in detail.

Tools to Check Your Setup

After publishing new DNS records, verify that they're syntactically correct and that authentication passes on outgoing mail. These tools handle the most common checks:

• MXToolbox (mxtoolbox.com): Enter your domain and select SPF, DKIM, or DMARC to check for syntax errors and misconfigurations. Covers all three record types in one place.
• mail-tester.com: Send a test email to a unique address provided by the tool. It returns a 10-point score covering authentication, content, and formatting, and identifies exactly which checks passed or failed.
• Google Postmaster Tools (postmaster.google.com): For domains already sending significant volume to Gmail, this dashboard shows domain reputation, authentication pass rates, and specific delivery error categories. Domain verification is required.
• dmarcian and DMARC Analyzer: Both parse DMARC aggregate reports into readable dashboards. Useful during the p=none monitoring phase to identify all sending sources before tightening policy.

DNS changes typically take up to 48 hours to propagate globally. If a record appears missing immediately after publishing, wait before treating it as a configuration error.

Starting the Setup

SPF, DKIM, and DMARC each address a different layer of the email trust problem. SPF authorizes sending servers. DKIM proves a message wasn't modified in transit. DMARC enforces a policy when either check fails and delivers the reports that show exactly what's happening with your domain's email.

The practical starting point: configure SPF and DKIM with your current email provider, then add a DMARC record at p=none with an rua= address. Use a reporting tool to review aggregate reports for a few weeks, confirm all sending services pass authentication, then move to p=quarantine. If this is part of a broader review of your online marketing strategy, treating email deliverability as a technical foundation, not an afterthought, is what keeps every other channel performing as expected.