Business Email: What Are SPF, DKIM and DMARC? Why Do Your Emails Land in Spam?

SPF, DKIM and DMARC are three DNS records that prove to receiving servers that emails sent from your domain really come from you. The short answer to "what is DMARC?" is this: it's a policy that matches the results of the SPF and DKIM checks against your "From" address and says what should happen to emails that fail that check. If these records are missing or wrong, your emails may land in spam at Gmail, Yahoo and other providers, or may not arrive at all.

Why do your emails land in spam?

When engineers first designed the email protocol, there was no mechanism to verify the "sender." As a result, anyone could put any address in the "From" line. Spoofing and phishing attacks exploit this gap.

Today, before placing an email in the inbox, the major email providers look at the answers to these questions:

• Is the server that sent this email authorized to send on behalf of this domain? (SPF)
• Did the domain owner sign the email, and did it arrive unaltered? (DKIM)
• Do these checks match the "From" address the user sees? If not, what does the domain owner want done? (DMARC)

If these records are missing or wrong, providers treat your email as "unauthenticated," however innocent it is. Of course, other factors matter too, such as spam complaints, broken links and content, but authentication is now a basic requirement.

What is SPF?

The IETF standard RFC 7208 defines SPF (Sender Policy Framework). It lets a domain owner publish in DNS the servers allowed to send email on behalf of that domain. The receiving server then checks whether the IP address that sent the email is on that list.

An SPF record is a TXT record and looks something like this:

“ ornekfirma.com.tr. TXT "v=spf1 include:_spf.ornek-saglayici.com ~all" “

• With include: you add your email provider's servers.
• The trailing ~all means "anything not on the list is suspicious," while -all means "reject anything not on the list."

What to watch for with SPF:

• A domain should have only one SPF record. Adding a separate v=spf1 record for each new service is a common mistake; instead, add a new include: to the existing record.
• The 10 DNS lookup limit. According to RFC 7208, the total number of terms that require a DNS lookup during SPF evaluation (include, a, mx, etc.) cannot exceed 10. If it does, the result is "permerror," meaning receivers treat the record as invalid. Between business email, a newsletter tool, a CRM and an invoicing system, this limit is easy to exceed.
• SPF checks the technical sender address, not the "From" address. That's why SPF alone doesn't stop forged "From" addresses. DMARC closes this gap.

What is DKIM?

RFC 6376 defines DKIM (DomainKeys Identified Mail). First, the sending server signs the email's headers and content with a private key. Next, the receiving server fetches the public key it needs to verify the signature directly from your domain's DNS records. This shows that the email really left under that domain's responsibility and nobody altered it in transit.

A DKIM record is also a TXT record, and you publish it under a selector name:

“ secici1._domainkey.ornekfirma.com.tr. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..." “

Selectors let a domain publish more than one key. For example, your business email provider uses one selector and your newsletter tool uses another. You don't generate the key value yourself; you copy it from your email provider's dashboard and add it to DNS.

What is DMARC?

RFC 7489 defines DMARC (Domain-based Message Authentication, Reporting and Conformance). It does two things:

1. Alignment check: It checks whether the domain verified by SPF or DKIM matches the domain in the "From" address the user sees. If they don't match, DMARC fails even if SPF or DKIM technically passes.
2. Policy and reporting: It says what to do with failing emails and arranges for receivers to send you reports.

You publish the DMARC record under the _dmarc subdomain:

“ _dmarc.ornekfirma.com.tr. TXT "v=DMARC1; p=none; rua=mailto:dmarc-rapor@ornekfirma.com.tr" “

The p= value takes one of three policies:

The rua= tag is the address for the aggregate reports that receiving servers send you. These reports show which servers are sending email on behalf of your domain. In other words, they're how you'll spot a sending tool you forgot about, or someone impersonating your domain.

Gmail and Yahoo's 2024 sender rules

Starting in February 2024, Google and Yahoo began enforcing authentication rules for senders. The core requirements in effect as of April 2025 are:

For all senders (Gmail):

• SPF or DKIM authentication
• Forward and reverse DNS (PTR) records for the sending server
• TLS encryption for sending email
• Keeping the spam rate in Postmaster Tools below 0.3%
• Emails that conform to the RFC 5322 format

For senders of roughly 5,000 or more emails a day (Gmail):

• SPF and DKIM set up together
• A published DMARC record (the policy can be p=none)
• For direct sends, the "From" domain aligned with SPF or DKIM
• One-click unsubscribe for marketing and subscription emails

Google says that once a sender crosses this threshold, Google permanently treats it as a bulk sender. It also counts emails sent from the same primary domain together. Bulk senders had until 1 June 2024 to implement one-click unsubscribe.

Yahoo put similar requirements in place in February 2024: at least SPF or DKIM for all senders; for bulk senders, SPF and DKIM together, a passing DMARC record with at least a p=none policy, one-click unsubscribe, and honoring unsubscribe requests within 2 days. In addition, both providers want the spam rate to stay below 0.3%.

Don't assume these rules don't concern you just because you don't send 5,000 emails a day. After all, the "all senders" requirements apply to everyone. Besides, setting up SPF, DKIM and DMARC together makes delivery more predictable for low-volume senders as well.

Step-by-step setup

1. Take inventory. List everything that sends email on behalf of your domain: business email, website forms, newsletter tool, CRM, e-invoicing or accounting software, help desk.
2. Combine SPF into a single record. Add each sending source with include: or by IP. Then check the 10-lookup limit.
3. Turn on DKIM for each source. Get the DKIM keys from each provider's dashboard, add them to DNS, then enable signing.
4. Start DMARC with p=none. Add a reporting address and monitor the reports for a few weeks.
5. Close the gaps. Fix the legitimate but unauthenticated sources you see in the reports.
6. Tighten the policy gradually. First quarantine, then reject. If you rush, receivers may reject your legitimate emails too.

If you don't know who manages your DNS records, start with our articles What is DNS? and What is a domain name?

Common mistakes

• Publishing two separate SPF records. Receivers may treat both as invalid.
• Forgetting website forms. WordPress forms often send through the server's own mail function. If that server isn't in SPF and doesn't add a DKIM signature, form notifications land in spam. Therefore, it's better to send forms through an authenticated SMTP account.
• Starting straight away with p=reject. Moving to a strict policy before seeing the reports can cut off a sending source you hadn't noticed.
• Never reading DMARC reports. A p=none policy doesn't protect you on its own; instead, its real value is in the reports.
• Not updating records when you change hosting or email providers. After a migration, the old SPF and DKIM records no longer work.

Our experience

In website projects, contact form notification emails and business email are part of the delivery checklist. When we launch a site, we review the domain's DNS records together with the client and test that form emails actually arrive. We also make sure the address the forms send notifications from is consistent with the domain's SPF and DKIM records.

Frequently asked questions

Conclusion

Getting your business emails delivered reliably is no longer just a matter of good content. In short, SPF defines sending authorization, DKIM the signature, and DMARC the validity of the "From" address and the policy. Since February 2024, the major providers have explicitly required these records.

If you'd like to review your website's form emails and your domain settings together, take a look at our web design and WordPress development services, or get in touch.