Why Business Emails Go to Spam: SPF, DKIM and DMARC Explained

Few business problems are more frustrating than sending a legitimate email and discovering that it landed in the recipient’s spam folder.

The email address may use a professional domain. The mailbox may be hosted by Google Workspace or Microsoft 365. The message may contain no obvious spam language. Yet the recipient still does not see it in the inbox.

The natural response is to search for a missing DNS record—usually SPF, DKIM or DMARC—and assume that adding it will solve everything.

Email authentication is essential, but the complete answer is more nuanced.

SPF, DKIM and DMARC help receiving systems determine whether a message is authorized and whether the visible sender matches the authenticated domain. They reduce spoofing, support domain trust and satisfy important sender requirements. They do not, by themselves, guarantee inbox placement.

Gmail, Outlook, Yahoo and other providers also evaluate reputation, recipient complaints, sending patterns, list quality, message structure, links, engagement signals and the history of the sending infrastructure.

This guide explains the entire problem in plain English: what SPF, DKIM and DMARC do, how they work together, why apparently correct records can still fail, and what to review when business emails go to spam.

Email delivery and email deliverability are not the same

These terms are often used interchangeably, but they describe different outcomes.

• Email delivery means the receiving mail server accepted the message. A delivered email may still go to spam.
• Email deliverability means the message reached the intended part of the recipient’s mailbox, ideally the inbox rather than spam, junk, quarantine, or another filtered category.

If a message bounces with an SMTP error, that is primarily a delivery problem. If the server accepts it but places it in spam, that is a deliverability problem.

Authentication affects both, but it is only one category of evidence used by mailbox providers.

The email journey in plain English

When you send an email from name@yourcompany.com, the recipient sees your domain in the visible From address. Behind the scenes, however, several other identities may be involved:

• The server or platform that transmitted the message
• The Return-Path or envelope-from domain used for bounces
• The domain shown in the DKIM signature
• The IP address of the sending server
• The links and tracking domains inside the message

The recipient’s mail system compares these signals. It asks:

1. Is this server permitted to send for the relevant domain?
2. Does the message carry a valid cryptographic signature?
3. Does an authenticated domain align with the domain the recipient can see?
4. Does the sender have a trustworthy history?
5. Did the recipient ask for this type of message?
6. Does the content or behavior resemble abuse?

SPF, DKIM and DMARC mainly answer the first three questions. Deliverability depends on all six.

SPF, DKIM and DMARC explained with one simple model

Think of a business sending a signed document through a courier.

• Email control: SPF; Plain-English role: Lists which sending systems are authorized; Courier analogy: A list of approved couriers
• Email control: DKIM; Plain-English role: Adds a verifiable signature to the message; Courier analogy: A tamper-evident company seal
• Email control: DMARC; Plain-English role: Checks whether authentication matches the visible sender and states a policy for failures; Courier analogy: Instructions to verify the seal and handle impostors

All three contribute to trust, but each checks something different.

What is SPF?

SPF stands for Sender Policy Framework. It is a TXT record published in DNS that identifies the servers and services permitted to send email for a domain.

An SPF record might look like this:

v=spf1 include:_spf.google.com include:example-email-platform.com ~all

This example says that Google and the named email platform are authorized senders. The ending tells receivers how to interpret sources that are not listed.

The exact record for a real organization may be completely different.

What SPF checks

SPF normally evaluates the domain used in the SMTP envelope—the Return-Path or mail-from identity—not necessarily the visible From address a person sees in their inbox.

That distinction is central to DMARC alignment. A message can pass SPF for a third-party platform’s domain while still failing to align with yourcompany.com.

Common SPF mistakes

Publishing more than one SPF record

A domain should not have several competing TXT records beginning with v=spf1. Multiple SPF policies can cause a permanent error instead of combining authorization.

If several services send mail, their authorized sources generally need to be represented in one valid policy.

Forgetting a legitimate sender

A business may think it sends only through Google Workspace, while its website forms, newsletter, invoicing platform, CRM, help desk and payment processor also send using the business domain.

If those systems are omitted or not configured with their own aligned authentication, some messages may fail even while ordinary staff email passes.

Leaving old services authorized forever

SPF records often accumulate include statements from platforms that are no longer used. This increases complexity, keeps obsolete senders authorized and can contribute to SPF lookup-limit problems.

Exceeding the DNS lookup limit

SPF evaluation permits a limited number of DNS-querying mechanisms. The standard limit is ten. Nested include statements can consume that allowance faster than the record appears to suggest, producing a permerror even when the TXT record looks tidy. The limit is defined in RFC 7208.

Assuming ~all or -all fixes reputation

The final mechanism affects how unauthorized sources are described, but changing it does not repair missing senders, DKIM, DMARC alignment, complaint rates or a damaged reputation. SPF must be designed from a complete sender inventory.

What is DKIM?

DKIM stands for DomainKeys Identified Mail. It adds a digital signature to an outgoing message.

The sending platform signs selected headers and message content using a private key. The receiving server retrieves the corresponding public key from DNS and verifies the signature.

If verification succeeds, the receiver gains evidence that:

• The signing domain took responsibility for the message; and
• The signed parts of the message were not altered after signing.

The DNS record is usually published at a hostname containing a selector, such as:

google._domainkey.yourcompany.com

or:

selector1._domainkey.yourcompany.com

Different services use different selectors, so several DKIM records can coexist without conflict.

DKIM is more than publishing a record

One of the most common Google Workspace mistakes is generating and publishing a DKIM key but not returning to the admin console to start authentication.

The DNS record makes the public key available. The sending system must also be configured to sign outgoing mail with the matching private key.

A DNS lookup alone cannot prove that live messages are being signed correctly. You must inspect a message that was actually sent.

Why DKIM often survives forwarding better than SPF

Forwarding can cause SPF to fail because the forwarding server is not listed in the original sender’s SPF policy. A valid DKIM signature may survive forwarding if the signed message content and headers remain unchanged.

This is one reason DMARC permits a message to pass through aligned DKIM even when aligned SPF does not pass.

However, mailing lists or security gateways that modify the subject, footer, links, or body can sometimes invalidate a DKIM signature.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance.

DMARC does three important things:

1. It checks whether SPF or DKIM passes in a way that aligns with the visible From domain.
2. It tells receiving systems what the domain owner wants done with messages that fail.
3. It can request reports that show who is sending mail using the domain.

A basic monitoring record might look like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com

This is an example, not a universal record. The reporting mailbox or analysis service must be able to handle machine-generated aggregate reports.

What DMARC alignment means

Suppose a recipient sees:

From: updates@yourcompany.com

DMARC does not merely ask whether SPF or DKIM passed somewhere. It asks whether at least one successful authentication path belongs to a domain aligned with yourcompany.com.

• SPF alignment compares the visible From domain with the SPF-authenticated envelope domain.
• DKIM alignment compares the visible From domain with the d= domain in a valid DKIM signature.

Under relaxed alignment, a related subdomain may qualify. Under strict alignment, the domains must match exactly. Most organizations begin with relaxed alignment unless they have a specific reason to require strict matching.

The three DMARC policy levels

• Policy: p=none; Requested treatment of messages that fail DMARC: Monitor without requesting quarantine or rejection; Appropriate use: Discovery and reporting
• Policy: p=quarantine; Requested treatment of messages that fail DMARC: Treat failures as suspicious, often placing them in spam; Appropriate use: Staged enforcement
• Policy: p=reject; Requested treatment of messages that fail DMARC: Reject messages that fail DMARC; Appropriate use: Strong enforcement after legitimate senders align

Starting with p=reject before identifying every legitimate sender can block real business email. A safer rollout begins with visibility, fixes authentication and alignment, then moves gradually toward enforcement.

What MX records do—and why they do not stop outgoing mail going to spam

MX stands for Mail Exchange. MX records tell other mail systems where to deliver incoming email for your domain.

If your MX records point to Google, that means Google handles mail sent to your domain. It does not prove that every message sent from your domain is authorized, aligned or reputable.

This distinction explains a common mystery: a company can receive email perfectly while its outgoing messages land in spam.

Inbound routing and outbound trust are different functions.

Why emails can still go to spam when SPF, DKIM and DMARC pass

Authentication is a foundation, not an inbox guarantee. A fully authenticated message can still look unwanted or risky for other reasons.

1. Poor domain or IP reputation

Mailbox providers build a history around domains and sending IPs. High complaint rates, invalid recipients, past abuse, sudden volume changes or association with a low-quality shared IP can weaken reputation.

If you use a large email service provider, the sending IP may be shared with other customers. The provider manages that pool, but recipient systems can still evaluate both the shared infrastructure and your individual domain.

2. Recipients did not clearly opt in

Sending to purchased, scraped, old, transferred or vaguely consented lists produces more complaints and less engagement. Even a technically perfect message is likely to perform badly if recipients do not recognize why they received it.

3. The list contains invalid or inactive addresses

Repeated hard bounces and long-term disengagement are negative signals. A large list is not automatically a valuable list; an engaged and permission-based audience is more useful.

4. Sending volume changed suddenly

A new domain that goes from a few messages per day to thousands has no stable history. An established sender that suddenly doubles its volume may also look unusual.

Google advises large senders to increase volume gradually, send at a consistent rate and monitor reputation and spam signals in Postmaster Tools.

5. Message identity is inconsistent

Switching From addresses frequently, using misleading display names, mixing transactional and promotional content, or sending different message types through the same identity can reduce clarity and trust.

For example, payment receipts, account alerts and marketing campaigns should not masquerade as one another.

6. Links or domains inside the email have a poor reputation

The sender domain may be healthy while a shortened URL, affiliate link, tracking domain or compromised destination has a bad reputation. Receiving systems evaluate more than the From address.

7. The message structure is broken or deceptive

Malformed headers, missing message IDs, misleading Re: subjects, hidden content, image-only designs, mismatched links or unusual HTML can contribute to filtering.

There is no dependable list of “spam words” that determines placement by itself. Context, behavior and reputation matter more than swapping a few phrases.

8. Unsubscribing is difficult

If readers cannot easily leave a list, they are more likely to click “Report spam.” That complaint is much more damaging than an ordinary unsubscribe.

Gmail requires qualifying marketing and subscribed mail from senders exceeding 5,000 messages per day to support one-click unsubscribe and include a visible unsubscribe link. Gmail also requires SPF, DKIM and DMARC for these bulk senders and says Postmaster Tools spam rates should remain below 0.3%, while recommending staying below 0.1%. These requirements are set out in Google’s current email sender guidelines.

Yahoo similarly requires bulk senders to authenticate with SPF and DKIM, publish DMARC, support easy unsubscribing and keep complaint rates low. See Yahoo’s sender best practices.

The hidden challenge: one domain may have many email senders

Most organizations do not have one email system. They have an ecosystem.

A publisher or small business might use:

• Google Workspace or Microsoft 365 for person-to-person email
• Ghost, WordPress or another CMS for newsletters and member emails
• Mailchimp, HubSpot or another marketing platform for campaigns
• Stripe, Odoo or another billing system for receipts and invoices
• A CRM for sales sequences
• A help desk for support replies
• A website form service for notifications or autoresponders
• A scheduling platform for confirmations
• A transactional provider such as Postmark, SendGrid, Mailgun or Amazon SES

Each platform can have its own SPF requirements, DKIM selectors, Return-Path domain and custom-domain settings.

This is why adding include:_spf.google.com does not authenticate everything sent from a business domain. It authorizes relevant Google infrastructure for SPF. It says nothing about whether a newsletter, invoice or contact-form message is correctly authenticated and aligned.

A practical email deliverability audit

When business emails go to spam, do not begin by randomly editing DNS. Start by collecting evidence.

Step 1: Build a sender inventory

List every service that sends or may send using your domain. For each one, record:

• Field: Platform; Example question: Is this Google Workspace, Ghost, Mailchimp, Stripe or another service?
• Field: Message type; Example question: Personal email, newsletter, receipt, password reset, form notification?
• Field: Visible From; Example question: What address does the recipient see?
• Field: Return-Path; Example question: Which domain handles bounces?
• Field: DKIM signing domain; Example question: What appears after d= in the DKIM signature?
• Field: Sending IP/provider; Example question: Which system actually transmitted the message?
• Field: Authentication status; Example question: Do SPF, DKIM and DMARC pass on a live test?
• Field: Business owner; Example question: Who knows whether the service is still active?

Do not remove a DNS entry merely because nobody immediately recognizes it. Trace it to a platform and confirm the platform’s status first.

Step 2: Review the DNS records

Check the domain for:

• Exactly one valid SPF policy at the relevant hostname
• Every legitimate sending service represented appropriately
• Obsolete SPF includes that can be retired after confirmation
• The SPF DNS lookup count
• DKIM records for each active sending service
• A DMARC record at _dmarc.yourcompany.com
• Typographical errors, duplicate records and invalid quotation marks
• Email verification CNAMEs that must remain DNS only
• Old records belonging to cancelled platforms

The presence of a record is not proof that live mail uses it. DNS review must be paired with message-header testing.

Step 3: Send a real test from every platform

Send a normal example of each message type to test accounts at major providers. Do not test only a blank email from the main mailbox.

Include:

• A staff email from the primary mailbox provider
• A newsletter
• A transactional or member email
• An invoice or receipt
• A form notification or autoresponder
• A CRM or sales message, if used

In Gmail, open the message menu and choose Show original. Look for the authentication summary and full headers.

Record whether SPF, DKIM and DMARC pass, but also record the domains involved. A green “pass” without alignment context can be misleading.

Step 4: Check alignment

For each message, compare:

1. The domain in the visible From address
2. The SPF-authenticated Return-Path domain
3. The DKIM d= signing domain

DMARC should pass through at least one aligned route.

If a marketing platform signs as its own generic domain and uses its own Return-Path, SPF and DKIM may both pass for that provider while neither aligns with your visible business domain. The solution is usually to complete the provider’s custom-domain authentication process, not to invent DNS values independently.

Step 5: Review reputation and complaints

For Gmail audiences, configure Google Postmaster Tools when sending volume is sufficient for data. Review:

• User-reported spam rate
• Domain reputation
• IP reputation
• Authentication results
• Delivery errors

Also review your sending platform’s bounce, complaint and unsubscribe data. Look for sudden changes by campaign, list source, mailbox provider, message type or sending domain.

Step 6: Review the list and sending practices

Ask:

• Did every recipient knowingly subscribe?
• Is confirmation used where appropriate?
• Are hard bounces suppressed automatically?
• Are chronically inactive contacts segmented or removed?
• Is the unsubscribe process immediate and easy?
• Did sending volume rise suddenly?
• Are marketing and transactional messages separated?
• Are From names and addresses consistent and recognizable?

Authentication cannot compensate for an audience that did not ask to hear from you.

Step 7: Inspect content and linked domains

Review the exact message that went to spam, including:

• Subject line and display name
• HTML validity and plain-text alternative
• Image-to-text balance and accessibility
• Link destinations and tracking domains
• URL shorteners
• Attachments
• Misleading reply/forward wording
• Sender identity and physical/contact information where applicable
• Visible and one-click unsubscribe behavior

Do not redesign every email based on one spam placement. Compare multiple providers, message types and recipients before identifying a pattern.

A safe SPF, DKIM and DMARC implementation sequence

Email authentication should be treated as a controlled rollout rather than three TXT records copied from a generator.

Phase 1: Discover

1. Inventory every sender.
2. Preserve the existing DNS zone and export a copy.
3. Test real messages from every platform.
4. Correct obvious SPF and DKIM failures using each provider’s instructions.
5. Publish DMARC at p=none with aggregate reporting when appropriate.

The goal is visibility without disrupting legitimate mail.

Phase 2: Align

1. Configure custom sending domains or Return-Path domains where supported.
2. Verify DKIM signing on live messages.
3. Consolidate the SPF policy and remove confirmed obsolete sources.
4. Resolve DMARC failures shown in reports.
5. Separate transactional and marketing identities where operationally useful.

The goal is for every approved sender to pass DMARC through aligned SPF, aligned DKIM, or both.

Phase 3: Enforce gradually

After reports show that legitimate traffic is aligned:

1. Move from p=none to a limited quarantine rollout.
2. Monitor failures, support reports and business systems.
3. Increase enforcement in stages.
4. Move toward p=reject when the organization is confident that unauthorized traffic can be rejected without harming legitimate mail.

DMARC percentage and subdomain policies can support staged deployment, but they should be designed for the organization’s actual mail architecture.

Phase 4: Maintain

Review authentication whenever you:

• Add or remove an email platform
• Migrate a website or CRM
• Change newsletter providers
• Introduce a new billing or support system
• Rebrand or add a sending domain
• See a sudden change in bounce, complaint or spam placement rates

DNS records are operational dependencies, not “set and forget” text.

Common email authentication mistakes to avoid

“My SPF passes, so my email is authenticated”

SPF may pass for a domain that does not align with the visible From address. Check DMARC, not only SPF.

“My DKIM record exists, so signing is enabled”

The sender must actively sign outgoing messages with the matching key. Inspect a real message header.

“DMARC at p=none stops spoofing”

p=none provides monitoring and visibility but does not ask receivers to quarantine or reject failing mail. It is a valuable first phase, not the final protection level.

“I should publish p=reject immediately”

Premature enforcement can reject legitimate mail from forgotten systems. Inventory, test and align before enforcing.

“I can add a second SPF record for the new platform”

Multiple SPF policies at one hostname are invalid. Consolidate authorization carefully.

“MX records prove my outgoing mail is legitimate”

MX records route incoming mail. They do not authenticate all outgoing senders.

“Authentication guarantees inbox placement”

Authentication improves legitimacy and is required in many sending scenarios, but providers still evaluate reputation, complaints, consent, content and sending behavior.

“The DNS test is green, so the problem is solved”

Static tools can confirm published records. Only live message tests show which domains and keys a sending platform actually used.

Frequently asked questions about business email going to spam

Why are my Google Workspace emails going to spam?

Possible causes include missing or inactive DKIM, incomplete SPF authorization, DMARC alignment failure, weak domain or shared-IP reputation, recipient complaints, sudden volume changes, suspicious links or sending through another platform using the same From domain. Test a real Google Workspace message and compare it with messages from every other sender on the domain.

Will SPF, DKIM and DMARC stop emails going to spam?

They improve authentication, reduce spoofing risk and help meet provider requirements. They do not guarantee inbox placement. Reputation, consent, list hygiene, complaints, content and sending patterns still matter.

Do small businesses need DMARC?

Yes, even low-volume domains benefit from knowing who sends on their behalf and reducing impersonation risk. Google requires DMARC for senders over its bulk threshold and recommends SPF, DKIM and DMARC for sending domains generally. Small organizations should still roll it out carefully.

What is the difference between SPF and DKIM?

SPF authorizes sending infrastructure for an envelope domain. DKIM attaches a cryptographic signature associated with a signing domain. DMARC can accept an aligned pass from either mechanism.

What is the difference between DKIM and DMARC?

DKIM verifies a signature. DMARC checks whether a successful SPF or DKIM identity aligns with the visible From domain and publishes a policy for messages that fail.

Can I have multiple DKIM records?

Yes. Different selectors allow multiple services or rotating keys to coexist. Each selector is published at a different DNS hostname.

Can I have multiple SPF records?

No. A hostname should have a single SPF policy. Authorization for multiple legitimate services must be combined correctly without exceeding SPF limits.

What DMARC policy should I use first?

For an established domain with multiple or uncertain senders, p=none with reporting is usually the safest discovery stage. Move toward quarantine and rejection only after legitimate mail is authenticated and aligned.

How quickly will fixing DNS improve email deliverability?

Authentication changes can begin working after DNS caches refresh and sending platforms use the new configuration. Reputation recovery may take much longer because mailbox providers need to observe sustained, healthy sending behavior. Re-test live headers after every change instead of relying only on time.

What should I ask a recipient to send me when an email lands in spam?

Ask for the full original message headers—not only a screenshot of the spam folder. In Gmail, the recipient can use Show original. Headers reveal authentication results, sending infrastructure, Return-Path, DKIM domain and routing history.

Conclusion: email deliverability is a system, not a single record

When legitimate business emails go to spam, SPF, DKIM and DMARC are the right place to begin—but the wrong place to stop.

The strongest diagnosis combines:

• A complete inventory of every sending platform
• Correct SPF authorization without duplicate records or excessive lookups
• Active DKIM signing for each sender
• DMARC alignment with staged enforcement
• Live message-header testing
• Domain and IP reputation monitoring
• Permission-based lists and easy unsubscribing
• Consistent, gradual and recognizable sending behavior

The key is not to ask, “Do we have an SPF record?” It is to ask, “Can every legitimate message prove who sent it, align with the domain the recipient sees, and arrive from a sender the recipient expects?”

If your staff emails, newsletters, invoices or website notifications are landing in spam, More X Tech can audit the complete sending ecosystem, map each DNS record to its owner, test live authentication and alignment, and provide a staged remediation plan without risking legitimate email through premature enforcement.