RFC 7489 or Gmail Sender Guidelines—Where Should a DMARC Review Start?
Decide where each DMARC claim belongs: RFC 7489 for protocol semantics and policy values, Google's sender guidelines for Gmail thresholds — and what to record when neither source proves it.
- 01Two Sources, Two Jobs
- 02Key Facts: What Each Source Says, Dated
- 03Does Gmail Require p=reject?
Start a DMARC review with two destinations, not one. RFC 7489, the RFC Editor’s March 2015 specification of Domain-based Message Authentication, Reporting and Conformance (DMARC), is where protocol semantics live — identifier alignment and the none, quarantine and reject policy values — while Google’s current email sender guidelines are where Gmail-specific volume thresholds and delivery requirements live. Route each claim in the sales brief to the source that can support it before you decide whether anything about a buyer has actually been proven.
For you, the email-security market-intelligence analyst who verifies DMARC claims for sales, this routing is the job. DMARC is a domain-level policy, validation and reporting mechanism built on Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) identifier alignment: a domain owner publishes a policy saying what receivers should do with mail that fails authentication. RFC 7489 defines the mechanism; Google’s sender page defines what one large receiver requires. A brief that cites a DMARC requirement without naming a source is already a finding — your first question is always “which document supports this sentence?”
Two Sources, Two Jobs
RFC 7489 is a standards document published by the RFC Editor in March 2015 and retrieved 2 August 2026. It answers “what is DMARC, and what do its terms mean?” It is the reference for semantics: alignment, the three policy values, and the rule that a passing SPF or DKIM check alone is insufficient unless the identifier’s domain aligns with the visible From domain. It prescribes nothing about any receiver’s requirements, and its normative text is fixed — standards change by revision, not by edit.
Google Workspace Admin Help’s email sender guidelines, accessed 2 August 2026, are platform policy, not protocol. They answer “what does Google require of senders mailing Gmail accounts?” For senders above 5,000 messages per day, Google requires SPF and DKIM, a published DMARC record, alignment of the direct-message From domain with SPF or DKIM, and one-click unsubscribe for marketing and subscribed messages — and explicitly allows the minimum DMARC enforcement policy to be p=none. This page changes: the current requirements took effect on 1 February 2024, and Google can update them again without a revision number.
In one pass: RFC 7489 has fixed authority for protocol meaning; Google’s page has current authority for Gmail delivery policy. Ask “what does the term mean?” of the first and “what does Gmail require at this volume?” of the second. Neither source proves anything about a specific buyer.
Key Facts: What Each Source Says, Dated
- RFC Editor, RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance, published March 2015, retrieved 2 August 2026. Policy values are none, quarantine and reject; reject asks receivers to reject messages that fail DMARC; a valid signature is insufficient unless its domain aligns with the visible From domain. https://www.rfc-editor.org/rfc/rfc7489
- Google Workspace Admin Help, “Email sender guidelines,” accessed 2 August 2026; current requirements effective 1 February 2024. Senders above 5,000 messages per day to Gmail accounts must use SPF and DKIM, publish DMARC, and align the direct-message From domain with SPF or DKIM; the minimum DMARC enforcement policy may be p=none; marketing and subscribed messages require one-click unsubscribe. https://support.google.com/a/answer/81126?hl=en
Measurement context: RFC 7489’s date shows how long the normative definition has been stable; Google’s effective date marks when current rules began applying. Both are standards or policy windows, not market events. A date in a brief (“since 2015,” “since February 2024”) describes when a rule became available or effective — it does not prove that a prospect has a DMARC gap, is being filtered, or is ready to buy.
Does Gmail Require p=reject?
Run the claim through both sources. RFC 7489 defines reject as the policy that asks receivers to reject messages failing DMARC; it is one of three values, and the specification does not tell any domain owner which to choose. Google’s guidelines say the minimum enforcement policy can be p=none and do not generally require p=reject. “Gmail requires p=reject” is therefore unsupported by either source: it mistakes a defined value for a mandate and ignores the page’s explicit allowance of p=none.
The claim survives because “publish a DMARC record” gets compressed into “publish the strictest DMARC record.” When you see that compression, name it. For a closer look at why the p=reject demand keeps appearing in sales language, our DMARC demand interpretation treats the demand as a signal about the person making it rather than a fact about Gmail.
Worked Example: Routing a Claim That Arrives in a Message
Illustrative Telegram message — composite, not from a real customer: “FYI, Gmail now forces p=reject on everyone, and any sender over 5,000 messages a day must have SPF, DKIM and DMARC aligned. One prospect is facing this now — they need to fix everything this quarter or risk spam. That’s our opening.”
Route each sentence:
- “Gmail now forces p=reject on everyone” — Google’s page allows p=none as the minimum. Unsupported.
- “Any sender over 5,000 messages a day must have SPF, DKIM and DMARC aligned” — correct for Gmail-bound volume above 5,000 per day, with the From-domain alignment clause. Supported, with the volume qualifier.
- “They need to fix everything this quarter” — no source sets a quarter deadline; Google sets requirements, not a buyer timeline. Unsupported.
- “That’s our opening” — a commercial inference about positioning, not an evidence claim. Labeled as opinion.
One sentence survives, two do not, one was never a fact. Record all four so the next brief starts from the matrix. The habit scales to any compliance citation: ask which source defines the obligation. For the full ladder of official-versus-vendor sources, see our official-source ladder note on compliance claims.
Why It Matters, and What Remains Unverified
Getting the destination wrong changes the question you hand to sales. Treat Google’s thresholds as protocol and the team overstates what every receiver enforces; treat RFC 7489 as the only source and the team misses that Gmail’s 5,000-per-day line is a real gate for a buyer’s outbound volume. Either error feeds a qualification conversation built on a claim neither source supports.
What remains unknown, and who verifies it: neither source proves that a prospect sends more than 5,000 messages per day to Gmail, uses customer relationship management (CRM) tools that authenticate those sends, or has any DMARC record at all. Only the prospect can confirm sending volume, receiver mix and current records; a pre-sales engineer or account team should ask, and you log the answer as unverified until they do. No date in either source establishes buyer intent, and no reading of either document does either.
The same discipline applies to claims that arrive as group chatter instead of briefs. TOP Prospect supports that habit at the input stage: it processes only Telegram groups you intentionally connect and are authorized to access, produces candidate signals for your review rather than fact certification, leaves every decision to a person, and does not contact group members automatically. That boundary follows Telegram’s own privacy policy (accessed 2 August 2026), which describes bots as independent third-party services whose permissions can be granted, changed or revoked. The Telegram business signal intelligence pillar explains the workflow.
FAQ
Does Gmail require p=reject?
No. Google’s email sender guidelines explicitly allow the minimum DMARC enforcement policy to be p=none and do not generally require p=reject. RFC 7489 defines reject as a policy value but does not mandate it.
Does RFC 7489 tell me what Gmail requires of bulk senders?
No. RFC 7489 defines DMARC semantics and policy values and sets no volume thresholds; it predates Gmail’s current sender requirements. Gmail-specific rules live in Google Workspace Admin Help’s email sender guidelines.
When a sales brief cites a DMARC requirement, how do I know which source to check?
Ask what kind of claim it is. Protocol meaning, alignment and policy values come from RFC 7489; Gmail volume thresholds and delivery requirements come from Google’s sender guidelines. If a claim fits neither, record it as unsupported and ask sales where it originated.
Next time a brief lands in your inbox, underline the DMARC sentences, write “RFC 7489” or “Gmail sender guidelines” in the margin of each, and see which ones survive contact with the actual text.
Frequently asked questions
Does Gmail require p=reject?
No. Google's email sender guidelines explicitly allow the minimum DMARC enforcement policy to be p=none and do not generally require p=reject. RFC 7489 defines reject as a policy value but does not mandate it.
Does RFC 7489 tell me what Gmail requires of bulk senders?
No. RFC 7489 defines DMARC semantics and policy values and sets no volume thresholds; it predates Gmail's current sender requirements. Gmail-specific rules live in Google Workspace Admin Help's email sender guidelines.
When a sales brief cites a DMARC requirement, how do I know which source to check?
Ask what kind of claim it is. Protocol meaning, alignment and policy values come from RFC 7489; Gmail volume thresholds and delivery requirements come from Google's sender guidelines. If a claim fits neither, record it as unsupported and ask sales where it originated. Next time a brief lands in your inbox, underline the DMARC sentences, write "RFC 7489" or "Gmail sender guidelines" in the margin of each, and see which ones survive contact with the actual text.
