SPF, DKIM, and DMARC Explained: The 2024 Gmail and Yahoo Rules Pakistani Senders Keep Failing

If you send bulk email from Pakistan — promo blasts on JazzCash offers, order confirmations from your Daraz-style store, or a weekly newsletter to 10,000 subscribers — and your open rates fell off a cliff sometime in February 2024, this is for you. Gmail and Yahoo changed the rules, and most local senders failed the same three checks. This is a hands-on teardown of email authentication SPF DKIM DMARC: what each record actually does, the exact DNS lines Pakistani senders get wrong, and how to fix them without paying a “deliverability consultant” PKR 80,000 to copy-paste a TXT record.

I have set up sending infrastructure for Pakistani clients since 2009 — back when SPF was the only thing anyone bothered with. The mistakes are predictable. Let’s go through them.

What Actually Changed: Gmail Sender Requirements 2024 (and Yahoo)

Starting February 2024, Google and Yahoo made authentication mandatory for “bulk senders” — anyone sending roughly 5,000+ messages per day to their users. Before this, you could limp along with a weak setup and still land in the inbox. Not anymore. Here is what they now require:

• SPF and DKIM both passing — not one or the other. Previously a lot of senders authenticated with only SPF and got away with it.
• A DMARC record published, even if it is the weakest possible policy (p=none). No DMARC record at all = rejected or junked for bulk volume.
• Domain alignment — the domain in your “From” address must align with the domain that passes SPF or DKIM. This is the one nobody in Pakistan understands, and it is why most “but I set up SPF!” complaints are still failing.
• A working unsubscribe (one-click, RFC 8058 list-unsubscribe header) and a spam complaint rate kept under 0.3%.

The bar is not high. The problem is that the typical Pakistani setup — a cPanel shared host plus a marketing tool like Mailchimp or SendGrid bolted on — almost guarantees an alignment mismatch unless someone configures it deliberately. Let’s break down each pillar.

SPF: The Record Everyone Has and Most People Break

SPF (Sender Policy Framework) is a TXT record in your DNS that lists which servers are allowed to send mail using your domain. When Gmail receives a message claiming to be from yourbrand.pk, it looks up your SPF record and checks whether the connecting server’s IP is on the approved list.

A correct SPF record looks like this:

• v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Here is what Pakistani senders break, in order of how often I see it:

1. The “too many DNS lookups” failure

SPF allows a maximum of 10 DNS lookups. Each include: counts. I regularly inspect records like include:_spf.google.com include:sendgrid.net include:mailgun.org include:spf.protection.outlook.com include:_spf.hostingprovider.pk include:zoho.com — stacked over years as the client switched tools and never removed the old ones. Once you exceed 10 lookups, SPF returns permerror and the whole thing fails. Fix: delete the includes for services you no longer use. You should have one, maybe two.

2. Two SPF records on the same domain

You are only allowed one SPF TXT record per domain. I have seen domains with one record from the hosting cPanel auto-setup and a second one the agency added for the email tool. Two records = automatic fail. Merge them into one line.

3. Using -all before you are ready

The suffix matters. ~all (softfail) says “anything not listed is suspicious but deliver it.” -all (hardfail) says “reject anything not listed.” Going straight to -all while you still send transactional mail from an unlisted server — say your custom PHP invoice script on a different VPS in Karachi — will silently kill those emails. Start with ~all, confirm every legitimate source is listed, then tighten.

DKIM Record Setup: The Cryptographic Signature

DKIM (DomainKeys Identified Mail) is stronger than SPF because it survives forwarding. Your sending server signs each message with a private key; the matching public key lives in your DNS. The receiver verifies the signature and knows the message was not tampered with and genuinely came from an authorized source.

DKIM record setup is where shared-hosting users in Pakistan stumble, because two things must happen and they usually only do one:

1. The sending platform generates a key pair and starts signing.
2. You publish the public key as a TXT (or CNAME) record at a specific selector subdomain — something like s1._domainkey.yourbrand.pk.

Common failures I clean up:

• Publishing the key but never enabling signing in the platform, or vice versa. Both halves are required. Mailchimp, SendGrid, and Google Workspace all have a one-click “authenticate domain” / “verify” button — actually click it after the DNS propagates.
• Copy-paste line breaks. DKIM public keys are long. When pasted into a cPanel DNS editor that wraps text, the key gets mangled and verification fails. Paste it as one unbroken string, or split it into proper quoted chunks the way the platform specifies.
• Wrong selector. If Google Workspace tells you to use selector google and you publish under default._domainkey, nothing matches. The selector in your DNS must match the selector the platform signs with.
• Old 1024-bit keys. If your DKIM was set up years ago with a 1024-bit key, rotate to 2048-bit. Google Workspace lets you regenerate; do it.

If you send from more than one platform — say Google Workspace for staff mail and a separate tool for newsletters — each needs its own DKIM selector published. They do not conflict; they coexist.

DMARC: The Record That Ties It Together

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer. It tells receivers what to do when SPF and DKIM checks fail, and — critically — it enforces alignment. This is the part of email authentication SPF DKIM DMARC that the 2024 mandate made non-optional.

A starter DMARC record is a TXT entry at _dmarc.yourbrand.pk:

• v=DMARC1; p=none; rua=mailto:[email protected]; fo=1

Alignment: the silent killer

Here is the trap. DMARC does not just check whether SPF or DKIM passed — it checks whether the domain that passed matches the domain in your visible “From” address. This is alignment.

Classic Pakistani failure: you send a campaign from [email protected] through a marketing tool. SPF passes — but it passes for the tool’s own bounce domain (something like bounce.mailtool.com), not yourbrand.pk. So SPF is “pass” but “not aligned.” If DKIM is also not signing with your domain, DMARC fails entirely even though both raw checks looked green. The fix is to set up a custom return-path / bounce domain (CNAME records the platform gives you) and DKIM signing with your own domain. Then both align, and DMARC passes.

The DMARC policy progression: p=none to p=reject

Do not publish p=reject on day one. I mean it. This is the single most damaging “advice” floating around — people read a blog that says “DMARC policy p=reject is the goal” and slam it in immediately, then their order confirmations, password resets, and that one report a vendor sends on their behalf all start bouncing into the void. Progress like this:

1. p=none for 2–4 weeks. Collect the aggregate (RUA) reports. This is monitoring only — nothing gets blocked. Read the reports to find every legitimate source sending as your domain.
2. p=quarantine; pct=25, then ramp the percentage. Failing mail goes to spam, not deleted. Watch for collateral damage.
3. p=reject only once your reports show 100% of legitimate mail passing aligned. Now spoofers get hard-rejected and your brand is protected.

DMARC setup Pakistan reality check: most local businesses can comfortably sit at p=quarantine and meet the Gmail/Yahoo requirement, because the mandate only needs a published policy plus passing auth, not necessarily p=reject. Reach p=reject when you are confident — and it does add real anti-phishing protection, which matters if scammers impersonate your brand to defraud customers over WhatsApp.

The Exact Checklist Pakistani Senders Keep Failing

Run through this before you send your next bulk campaign. If any item is “no,” your email deliverability authentication is incomplete.

• One — and only one — SPF record, under 10 DNS lookups, listing every server you actually send from, ending in ~all or -all.
• DKIM signing enabled in the platform AND the matching public key published at the correct selector, as one unbroken string, 2048-bit.
• A DMARC record at _dmarc with at minimum p=none and a working rua= mailbox you actually read.
• Custom return-path / bounce domain configured so SPF aligns with your From domain.
• DKIM signing with your domain (not the platform’s) so DKIM aligns.
• One-click list-unsubscribe header present on bulk mail.
• Spam complaint rate under 0.3% — which means clean your list and stop emailing people who never opted in (buying a “50,000 Pakistani emails” Excel sheet off Facebook is exactly how you blow past 0.3%).

How to actually verify it

Do not trust the platform’s green checkmark alone. Send a test email to a Gmail address, open it, click the three dots, and choose “Show original.” You will see SPF: PASS, DKIM: PASS, and DMARC: PASS with the domains listed. If any says fail or the mailed-by/signed-by domain is not yours, you have an alignment problem. Free tools like MXToolbox and Google’s own Postmaster Tools (set it up — it shows your domain reputation and spam rates) confirm the rest.

Why This Is Not Just a Technical Chore

Authentication is the floor, not the ceiling. Passing SPF, DKIM, and DMARC gets you eligible for the inbox — it does not guarantee placement. Reputation does the rest, and reputation is built on engagement: people opening, replying, and not marking you as spam. That is where list hygiene and content quality matter, and where a structured email marketing strategy pays off more than any DNS tweak.

It also intersects with the rest of your stack. A clean sending domain protects your brand from impersonation, which feeds into online reputation management when scammers try to spoof you. And the landing pages your emails point to need to convert — weak design wastes good deliverability, which is why we usually look at web design and conversion alongside email work. The records are the entry ticket; the campaign is the show.

Frequently Asked Questions

Do these Gmail and Yahoo rules apply to me if I send fewer than 5,000 emails a day?

The strict “bulk sender” thresholds target 5,000+ per day, but the safe answer is: set up SPF, DKIM, and DMARC regardless. Gmail has been quietly tightening for all senders, and a small sender with no authentication still lands in spam more often. There is no downside to doing it properly even at 200 emails a week.

My host says SPF is “already set up.” Why are my emails still going to spam?

Almost always alignment. Your host’s default SPF covers mail sent through their server, but your campaigns go through a third-party tool whose SPF does not align with your From domain. You also likely have no DKIM signing with your own domain and no DMARC record. The host technically isn’t lying — the setup just doesn’t meet the 2024 requirements.

Can I use a Gmail or Yahoo address as my From address for bulk sending?

No, and this is now explicitly penalized. Sending bulk mail “from” a free @gmail.com or @yahoo.com address through a marketing tool fails DMARC because you cannot publish authentication records for Google’s domain. Use your own domain — [email protected] — which you control and can authenticate.

How long does DNS propagation take in Pakistan?

DNS is global, so propagation isn’t a Pakistan-specific thing — it depends on the TTL on your records, typically 30 minutes to a few hours, occasionally up to 24–48 hours for stubborn resolvers. Lower the TTL before making changes if you want faster turnaround. Verify with a lookup tool rather than guessing.

Is jumping straight to p=reject dangerous?

Yes. Going to p=reject before confirming every legitimate sending source passes aligned will hard-bounce real mail — invoices, resets, vendor notifications — with no warning. Sit at p=none, read your DMARC reports, move to p=quarantine, and only reach p=reject once the data shows you are clean.

Do I need to pay for a DMARC monitoring service?

Not to start. The free tier of a DMARC report parser is enough for most Pakistani SMEs to read the XML aggregate reports. Paid services help when you have many sending sources and want dashboards, but do not let a vendor convince you it is mandatory just to meet the Gmail/Yahoo rules.

Get Your Sending Domain Audited Properly

If your open rates dropped, your campaigns are landing in spam, or you simply want to confirm you meet the Gmail sender requirements 2024 before your next big send, we will check it for you. One Source Soft has handled deliverability and authentication for Pakistani senders for over a decade, and our public Google reviews reflect that hands-on, no-nonsense approach. We will read your actual DNS, find the broken record, and tell you straight what to fix — no PKR 80,000 surprise invoice for a single TXT line.

Start with a free deliverability audit. Talk to us through our email marketing service or reach out directly via the contact page, and we will tell you exactly where your SPF, DKIM, and DMARC stand — and what it takes to get back into the inbox.