DMARC is a core part of modern email authentication.
Major mailbox providers now expect properly authenticated email, particularly from organizations sending at higher volumes. Google requires SPF or DKIM for all senders to Gmail accounts and requires SPF, DKIM, and DMARC for senders sending roughly 5,000 or more messages per day to personal Gmail accounts. Google also requires the visible From domain to align with either SPF or DKIM for bulk senders.
Shape handles the applicable email authentication for Shape sending during onboarding. That typically includes configuring the domain or subdomain Shape will use and providing the DNS records needed for the sending setup.
DMARC is broader than Shape, though.
Your organization’s DMARC policy can affect email sent through:
- Shape
- Google Workspace
- Microsoft 365
- Marketing platforms
- Customer support platforms
- Billing systems
- HR or recruiting software
- Website applications
- Transactional email services
- Other third-party systems using your domain
This guide explains how DMARC works, the difference between p=none, p=quarantine, and p=reject, and what to consider before changing your organization’s DMARC policy.
What Is DMARC?
DMARC stands for Domain-based Message Authentication, Reporting & Conformance.
It works together with two other email authentication technologies:
- SPF, or Sender Policy Framework
- DKIM, or DomainKeys Identified Mail
SPF and DKIM authenticate different parts of an email message.
DMARC adds another important check: domain alignment.
That means the domain being authenticated by SPF or DKIM needs to appropriately align with the domain the recipient sees in the email’s From address.
Microsoft describes SPF, DKIM, and DMARC as interdependent technologies that work together for effective email authentication. DMARC specifically helps address the alignment gap left by SPF and DKIM on their own.
Why DMARC Matters More Today
DMARC used to be discussed primarily as an email security best practice.
It is still important for security, but mailbox-provider requirements have made authentication much more operationally important.
Google currently requires bulk senders to personal Gmail accounts to use:
- SPF
- DKIM
- DMARC
- DMARC alignment
- TLS
- One-click unsubscribe for applicable marketing and subscribed messages
- A visible unsubscribe option in those messages
Google allows the DMARC policy itself to remain at p=none, meaning you do not need to immediately move to quarantine or rejection simply to establish DMARC.
Google also began increasing enforcement against noncompliant bulk-sender traffic in November 2025, including temporary and permanent rejection of messages that fail its sender requirements.
So the question today is less “Should we have DMARC?” and more “What DMARC enforcement level is appropriate for our organization?”
How Shape Handles Email Authentication
Shape generally handles the Shape-specific email authentication setup during onboarding.
Our team works with you to:
- Identify the appropriate business domain or sending subdomain.
- Generate the DNS records required for Shape email.
- Provide those records to your domain or IT administrator.
- Verify that the records are publicly resolving.
- Complete the Shape email configuration.
This gives email sent through Shape the authentication foundation required for the configured sending environment.
For more information about that process, see the Email Domain Authentication & Email Deliverability Best Practices guide.
What Shape Authentication Does Not Mean
Successfully authenticating Shape does not automatically mean every other application sending email from your organization is correctly configured.
For example, Shape email may be properly authenticated while another platform using the same organizational domain is not.
That distinction becomes particularly important before changing an organization-wide DMARC policy to p=quarantine or p=reject.
A stricter DMARC policy can affect legitimate email from other systems if those systems are not properly authenticated and aligned.
How SPF, DKIM, and DMARC Work Together
It helps to understand the role of each technology.
SPF
SPF identifies the mail systems authorized to send email for a particular domain.
It essentially answers: “Is this sending server authorized to send for this envelope domain?”
SPF by itself does not verify that the authenticated domain matches the From address the recipient sees.
DKIM
DKIM adds a digital signature to the email.
Receiving systems can verify that signature using a public DNS record associated with the signing domain.
It helps answer: “Was this message signed by a domain with the appropriate key, and has the signed content remained intact?”
DKIM alone also does not require the signing domain to match the visible From domain.
DMARC
DMARC connects those authentication results to the domain shown to the recipient.
For DMARC to pass, an applicable SPF or DKIM result must pass and align with the From domain.
That alignment requirement is one reason DMARC is so important.
What Is DMARC Alignment?
Consider an email sent from offers@yourcompany.com.
A message might technically pass SPF using one domain while displaying yourcompany.com to the recipient.
DMARC evaluates whether those domains align appropriately.
For Gmail bulk senders, the organizational domain in the visible From header must align with either the SPF organizational domain or the DKIM organizational domain. Google requires both SPF and DKIM to be configured for bulk senders, although only one needs to align to satisfy the current DMARC alignment requirement.
This is why simply having an SPF record somewhere is not enough.
The Three DMARC Policies
A DMARC record includes a policy telling receiving mail systems what your domain requests they do when a message fails DMARC.
There are three primary policies:
- p=none
- p=quarantine
- p=reject
p=none: Monitor
A p=none policy establishes DMARC without requesting that failing messages be quarantined or rejected because of the DMARC policy itself.
An example might look like:
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
This is often called the monitoring policy.
Why p=none Is Useful
A monitoring policy lets your organization begin collecting DMARC information without immediately enforcing DMARC failures.
This can help identify:
- Legitimate email systems
- Unknown senders
- Authentication failures
- Alignment problems
- Systems that still need to be configured
It is particularly useful when your organization has multiple platforms sending email.
Is p=none Still Valid?
Yes.
Google specifically allows bulk senders to use a DMARC policy of p=none while meeting its DMARC requirement.
Google also recommends DMARC generally, including minimal-enforcement configurations when appropriate.
What p=none Does Not Mean
p=none does not guarantee that a failing message will reach the inbox.
It simply means the DMARC record is not requesting quarantine or rejection based on the DMARC failure.
Receiving systems can still use their own spam, reputation, authentication, and security systems when deciding whether to:
- Deliver the message
- Send it to spam
- Temporarily reject it
- Permanently reject it
p=quarantine: Increased Enforcement
A quarantine policy asks receiving providers to treat messages that fail DMARC as suspicious.
Example:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com
Depending on the receiving provider, a failing message might be routed to:
- Spam
- Junk
- Another restricted area
The receiving provider ultimately determines how the message is handled.
When to Consider p=quarantine
An organization may consider increased enforcement after it has:
- Identified its legitimate sending systems
- Reviewed DMARC reporting
- Confirmed important senders are authenticated
- Corrected known alignment problems
- Tested normal business email flows
This is often a useful intermediate step before full rejection.
p=reject: Strongest Enforcement
A reject policy asks receiving providers to reject messages that fail DMARC.
Example:
v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com
This provides the strongest DMARC enforcement against direct-domain spoofing.
It can also create the greatest disruption if legitimate sending services are not properly authenticated.
Before Moving to p=reject
Before applying a reject policy, make sure your organization understands all systems sending email from the domain.
That can include:
- Shape
- Employee email
- Google Workspace
- Microsoft 365
- Transactional applications
- CRM platforms
- Marketing platforms
- Help desk systems
- Recruiting systems
- Billing applications
- Website forms
- Scheduling applications
- Internal applications
If one of those services is legitimate but does not authenticate and align correctly, a p=reject policy may cause receiving systems to reject its messages.
For that reason, successfully authenticating Shape by itself is not a reason to immediately move your entire organizational domain to p=reject.
Which DMARC Policy Should We Use?
There is no single enforcement policy that is appropriate for every organization.
A common progression is:
p=none → review → p=quarantine → review → p=reject
This lets you increase enforcement as your understanding of the domain improves.
The goal is not to reach p=reject as quickly as possible.
The goal is to apply the strongest policy that your organization can confidently support without disrupting legitimate email.
Current Mailbox Provider Requirements
Email authentication requirements have changed substantially in recent years.
Gmail
Google currently requires all senders to Gmail accounts to use SPF or DKIM.
Senders sending approximately 5,000 or more messages per day to Gmail accounts must also use:
- SPF
- DKIM
- DMARC
- DMARC alignment
- TLS
- Appropriate DNS
- Low spam complaint rates
Applicable marketing and subscribed messages must also support one-click unsubscribe and include a clearly visible unsubscribe option.
Shape automatically provides unsubscribe functionality on applicable marketing and bulk email messages as part of the Shape email workflow.
Google also recommends that senders use strong authentication generally because authenticated messages are less likely to be rejected or marked as spam.
Microsoft
Microsoft also treats SPF, DKIM, and DMARC as important building blocks of email authentication and anti-spoofing protection. Microsoft 365 evaluates these technologies along with additional authentication and reputation signals.
Mailbox-provider requirements can change, so organizations sending substantial email volume should periodically review the current sender requirements for the providers their customers use.
Setting Up a DMARC Record
DMARC is published as a TXT record in your domain’s DNS.
Before creating or changing your policy, first understand your legitimate sending environment.
Step 1: Identify Your Sending Sources
Make a list of services that send email using your domain.
Do not limit the list to your normal employee email.
Check with departments such as:
- Sales
- Marketing
- Customer Service
- Accounting
- Operations
- HR
- IT
A system that only sends a handful of emails may still matter if those messages are business-critical.
Step 2: Confirm Shape Authentication
If you are onboarding with Shape, make sure the DNS records supplied by Shape have been added and verified.
Shape handles the authentication required for the Shape sending setup.
Step 3: Review Other Sending Services
Confirm that other legitimate systems are also configured appropriately.
This may require working with:
- Your IT team
- Your email administrator
- The sending platform
- Your DNS administrator
Step 4: Publish the DMARC Record
A basic monitoring record might look like:
v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com
In this example:
- v=DMARC1 — Identifies the DMARC version.
- p=none — Sets the monitoring policy.
- rua=mailto: — Specifies where supported aggregate DMARC reports should be sent.
Your organization’s DMARC record may contain additional options.
Step 5: Add the Record to DNS
Create a TXT record using:
Type: TXT
Host or Name: _dmarc
Value: Your DMARC policy
The exact DNS interface depends on the company managing your DNS.
Step 6: Verify the Record
Allow time for DNS propagation and verify that the DMARC record is publicly available.
Step 7: Review Results Before Increasing Enforcement
Do not move to a stricter DMARC policy simply because the DNS record exists.
Review whether legitimate email is actually authenticating correctly.
DMARC Aggregate Reports
The rua portion of a DMARC record can specify where aggregate reports should be sent.
These reports can provide information about email appearing to originate from your domain, including:
- Sending IP addresses
- Message volume
- SPF results
- DKIM results
- DMARC results
- Policy disposition
- Authentication domains
These reports are typically delivered as XML files and can be difficult to read manually.
Organizations with meaningful email volume may want to use a DMARC reporting or analysis service to make the information easier to interpret.
Why DMARC Reports Matter
Organizations often have more legitimate email senders than expected.
For example:
- Your sales team may use Shape.
- Your employees may use Microsoft 365.
- Marketing may use another email platform.
- Accounting may use separate billing software.
- Support may use a ticketing platform.
A monitoring period can help surface those senders before stricter enforcement is introduced.
DMARC and Subdomains
Organizations often use subdomains for different email services.
For example:
- email.yourcompany.com
- marketing.yourcompany.com
- notifications.yourcompany.com
Shape may use an authenticated sending subdomain as part of its email configuration.
DMARC supports controls for subdomains, including the sp tag.
The sp tag is not inherently problematic, but it should only be configured when your organization understands how its subdomains are being used.
Avoid applying a broad subdomain enforcement rule simply because it appears more secure.
A subdomain may be used by an important legitimate system that requires separate review.
Common DMARC Problems
Legitimate Email Is Failing DMARC
Check:
- SPF
- DKIM
- Domain alignment
- Which service sent the message
- Whether the service has changed its sending infrastructure
- Whether the message was forwarded
- Whether another system modifies the message in transit
A DMARC failure does not automatically mean the message was malicious.
Microsoft notes that legitimate forwarding and services that modify messages in transit can sometimes affect traditional authentication results.
Shape Emails Are Failing DMARC
If email sent through Shape appears to be failing SPF, DKIM, or DMARC unexpectedly, contact Shape Support.
Our team can review the applicable Shape authentication configuration and verify whether the required DNS records are resolving correctly.
An Unknown Sender Appears in DMARC Reports
Investigate before assuming the sender is malicious.
It could be:
- An old service that is still active
- A new vendor
- An internal application
- A marketing platform
- A legitimate forwarded message
- An improperly configured sender
- Unauthorized use of your domain
The monitoring phase is designed to help identify these situations.
Legitimate Email Stopped Delivering After Changing DMARC
If the problem began after changing p=none → p=quarantine or p=quarantine → p=reject, review your authentication results.
A legitimate sender may not have been properly configured before enforcement was increased.
If the affected email was sent through Shape, contact Shape Support.
If it came from another platform, work with that provider or your email administrator.
DMARC Is Not an Inbox Guarantee
A message can pass SPF, DKIM, and DMARC and still be filtered.
Receiving providers consider many additional signals, including:
- Sender reputation
- Domain reputation
- IP reputation
- Bounce rate
- Spam complaints
- Recipient engagement
- Sending volume
- Sending patterns
- Content
- Unsubscribe behavior
Google explicitly requires bulk senders to maintain spam rates below its published threshold in addition to meeting authentication requirements.
DMARC is an important part of email deliverability, but it is only one part.
Use Gmail Postmaster Tools When Appropriate
Organizations sending meaningful volume to Gmail accounts can use Google Postmaster Tools to review information about their sending domain.
Google’s current dashboards include a Compliance Status view that can help senders evaluate whether they are meeting Gmail’s sender requirements.
Postmaster Tools can be especially useful for organizations that:
- Send high email volume
- Regularly send bulk campaigns
- Are troubleshooting Gmail deliverability
- Want additional visibility into sender reputation and authentication
Frequently Asked Questions
Is DMARC still optional?+
That depends on your sending environment.
Google requires DMARC for senders sending roughly 5,000 or more messages per day to personal Gmail accounts and recommends email authentication more broadly.
For organizations sending business email today, DMARC is increasingly part of a standard email authentication setup rather than an unusual advanced configuration.
Does Shape handle email authentication?+
Yes. Shape handles the applicable Shape email authentication configuration during onboarding.
This includes working with your organization to authenticate the domain or subdomain used for email sent through Shape.
Does Shape control our company’s DMARC policy?+
No.
Shape can help authenticate email sent through Shape, but your organization’s DMARC record may affect every service using your domain.
Your broader DMARC policy should be managed by the person or team responsible for your domain, DNS, or email infrastructure.
If Shape is authenticated, can we use p=reject?+
Shape authentication confirms the applicable Shape sending configuration.
Before moving the organizational domain to p=reject, confirm that all other legitimate email systems using that domain are also properly configured.
Is p=none a real DMARC policy?+
Yes.
p=none establishes DMARC and enables monitoring without requesting quarantine or rejection.
Google permits p=none for its current bulk-sender DMARC requirement.
Should everyone start with p=none?+
Not necessarily.
If your organization already has a mature, monitored DMARC configuration, there may be no reason to reduce enforcement.
p=none is primarily useful when you need visibility before applying stronger enforcement.
Does p=none mean every message goes to the inbox?+
No.
Receiving email providers still apply their own filtering and security systems.
What does p=quarantine do?+
It asks receiving providers to treat DMARC-failing messages as suspicious.
They may route those messages to spam or handle them another way.
What does p=reject do?+
It asks receiving providers to reject messages that fail DMARC.
Does passing DMARC guarantee delivery?+
No.
Authentication is only one of many deliverability signals.
Does DMARC replace SPF or DKIM?+
No.
DMARC relies on SPF and DKIM authentication and alignment.
Do bulk senders need both SPF and DKIM?+
For Gmail’s current bulk-sender requirements, yes. Google requires both SPF and DKIM, plus DMARC.
Does Shape support email unsubscribe requirements?+
Shape automatically includes unsubscribe functionality on applicable marketing and bulk emails.
What happens if we don’t meet Gmail’s sender requirements?+
Google states that noncompliant traffic can experience delivery disruptions, including temporary or permanent rejection.
How do I know whether our other sending platforms are authenticated?+
Review your DMARC reports and work with your IT or email administrator.
Each third-party sending platform can also provide instructions for configuring its SPF, DKIM, and domain alignment.
Can Shape troubleshoot another vendor’s DMARC setup?+
Shape can help troubleshoot the email authentication used for Shape.
We may not have access to the configuration or sending infrastructure of another platform.
A Practical DMARC Approach
For organizations that are still establishing DMARC, a practical process is:
- Make sure Shape and your other legitimate sending platforms are authenticated.
- Publish a valid DMARC record.
- Begin with monitoring when appropriate.
- Review DMARC aggregate reports.
- Identify every legitimate sending source.
- Correct SPF, DKIM, or alignment problems.
- Investigate unknown senders.
- Increase enforcement when your organization is comfortable doing so.
- Continue monitoring after changing the policy.
Modern mailbox providers increasingly expect authenticated email.
Shape takes care of the applicable authentication for email sent through Shape during onboarding, but DMARC protects and governs a broader email ecosystem.
The safest approach is to make sure Shape is authenticated, understand what else sends on behalf of your domain, monitor the results, and then choose the DMARC enforcement level that fits the organization as a whole.