StrategyCore
Back to Resources
01/cybersecurity 2 min read

DMARC in Japan: explain the protection and its limits

A practical basis for evaluating email authentication with Japanese prospects.

DMARC helps an organisation protect its sending domains against impersonation. The work begins with identifying legitimate mail services and checking their authentication, then agreeing how to handle failures. Explain what DMARC covers and what it does not: a policy record does not prove that every phishing attempt will be stopped.

DMARC checks and receiver handling

SC-FL-02 · REV A · 2026.07

01SPF or DKIM

authenticate

02From-domain alignment

DMARC

03Published policy

none / quarantine / reject

04Receiver decision

local controls

Illustrative flow. Neither DMARC success nor a published reject policy guarantees a particular delivery outcome.

An authenticated identifier is compared with the visible From domain; the receiver uses the result and other signals to decide handling.
01

What DMARC checks

DMARC evaluates whether the domain in the visible From address aligns with a passing SPF or DKIM result. Either aligned mechanism can provide a pass. The domain owner publishes a policy for failures and can request reports. The receiver still decides how to handle a message under its own policy; authentication success does not guarantee inbox delivery.

02

Choose a policy for the actual mail flows

p=none expresses no preference for handling failures. p=quarantine marks failures as suspicious; p=reject indicates the domain owner considers them invalid. Both enforcement policies require care with forwarding and mailing lists. RFC 9989, published in May 2026, replaced RFC 7489 and removed the older pct tag. A proposal should identify the standard and receiver behaviour it relies on.

03

Keep provider requirements separate from regulation

Google and Yahoo publish bulk-sender authentication requirements that permit a minimum DMARC policy of p=none. Microsoft introduced requirements for high-volume senders to its Outlook.com consumer service in May 2025. These are provider rules with defined scopes, not a universal Japanese legal requirement to publish p=reject. Check the prospect’s applicable guidance and procurement conditions separately.

04

Agree which domains and sending services to evaluate

Inventory domains, subdomains, SaaS senders and forwarding paths. Assign an owner to each legitimate service, verify alignment and agree how failures will be investigated before changing policy. SPF evaluation has a limit on DNS-querying mechanisms and modifiers; managed SPF still has to produce standards-compliant results. Review lookalike-domain monitoring, account protection and payment-verification procedures alongside DMARC.

Sources and further reading

// Key Takeaways

What to remember

  • An aligned SPF or DKIM pass is sufficient for DMARC.
  • The receiver retains control of message disposition.
  • Separate bulk-sender rules, prospect requirements and legal obligations.

// FAQ

Frequently asked questions

Q1

Does p=reject stop every phishing message?

No. It concerns authentication of the protected From domain. Lookalike domains, compromised accounts and other social engineering need additional controls; receivers also apply their own handling policy.

Q2

Do bulk-sender rules always require p=reject?

No. Google, Yahoo and Microsoft’s cited consumer-service requirements allow p=none as the minimum DMARC policy. Authentication, alignment and other provider requirements still apply within their stated scopes.

Last updated:

Develop Japanese sales for your email security product.

Bring your product’s authentication functions, supported sending services and migration requirements. Our Tokyo team can organise Japanese demonstrations, work with prospective buyers on technical questions and handle proposals, licensing and agreed support.