In preparation for February 2024 changes Gmail has announced Acoustic is taking actions to ensure our clients’ email meets Google’s authentication standards. One of those standards is DMARC.
What Is DMARC?
DMARC stands for “Domain-based Message Authentication, Reporting & Conformance”, an email authentication, policy, and reporting protocol. It builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (“From:”) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email.
What does this mean for my company?
DMARC builds upon two other authentication methods: Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). DMARC empowers domain owners to define how incoming emails to ISPs & Corporate Email Software should be treated if the emails fail SPF and DKIM checks, offering an added layer of email security. It simply requires a DNS entry, which allows you to define a policy that tells receiving mail servers what to do with unauthenticated email from your domain.
What is a DMARC policy?
Each DMARC record needs to define a policy to handle SPF and DKIM authentication failures, which can be defined as:
- None: No action. Message should be delivered.
- Quarantine: Failures should be quarantined, generally sent to the spam folder.
-
Reject: Message failures will be rejected.
- This policy lets an inbox provider know what to do with email that does not meet authentication standards.
Gmail’s minimum requirement for DMARC is p=none. P=none instructs the receiving mailbox provider to take no action on an email that fails an SPF/DKIM check.
Learn more about DMARC policy options.
What is DMARC reporting?
DMARC can be configured to receive regular reports from email servers that get email from your domain. The recipient of these reports is defined in the DMARC DNS record (“Mailto:”). For more information go to https://support.google.com/a/answer/10032472?hl=en
Report types
There are two different report types that DMARC can generate:
- RUF reports: which are generated per un-authenticated incident
- RUA reports: daily digests of un-authenticated incidents
Some reasons why you might want DMARC reports:
- Email security: DMARC reports can help you identify unauthorized use of your domain in phishing or spoofing attacks. By receiving reports on failed authentication attempts, you can take action to protect your domain and brand reputation.
- Email deliverability: Monitoring DMARC reports can help you identify email deliverability issues. If legitimate emails are failing DMARC checks, it may affect their delivery to recipients’ inboxes. Understanding these issues can help you address them and improve your email deliverability.
- Compliance: Some organizations, particularly in certain industries or sectors, may have regulatory requirements that mandate the use of DMARC and the monitoring of DMARC reports for email security and compliance purposes.
- Brand protection: DMARC can help protect your brand reputation by preventing malicious actors from using your domain for fraudulent purposes. The reports can give you insight into how your domain is being abused.
- Continuous improvement: By analyzing DMARC reports, you can continuously improve your email authentication setup and reduce the likelihood of email-related security incidents.
Interpretation of reporting
- Aggregate reports (RUA): These reports provide statistical data on the delivery and authentication status of email messages sent on behalf of your domain. They can help you understand how many emails are passing or failing DMARC authentication checks, which can be useful for monitoring the overall health of your email authentication setup.
- Forensic reports (RUF): These reports provide detailed information about individual email messages that failed DMARC checks, including the message’s header and body. Forensic reports are especially valuable when you want to investigate specific incidents of email abuse or phishing attacks using your domain.
How do I know if my company already uses DMARC?
- Ask your IT team to check your DNS record for a TXT record that begins with “_dmarc”.
- Use these online tools.
- https://toolbox.googleapps.com/apps/dig/
- In the Name field, enter _dmarc. followed by your complete domain name. For example, enter _dmarc.example.com
- Below the Name field, click TXT.
- Verify your DMARC TXT record name in the results. Look for the line of text that starts with _dmarc.
What does my company need to do next?
For customer domains NOT hosted by Acoustic: We strongly suggest you add a DMARC record into your DNS, if you don’t already have one.
- At minimum, you should have a DMARC record present to properly authenticate to ISPs like Gmail and Yahoo!. The baseline entry would look like the following: ‘v=DMARC1; p=none;’
- Formatting of the record is dependent on your DNS provider (e.g. Godaddy, registrar.com, etc). Consult your DNS provider for proper formatting of the record.
- More information on how to construct your record can be found here.
- Here are a couple of examples of DMARC DNS for your reference to help you identify how the DNS looks which you will need to set with your Domain DNS provider or IT. If you set the DMARC record on the root domain then DMARC will be automatically inherited/set for any subdomain of the root domain record (unless a different DMARC DNS is set for the sub domain):
- Subdomain: _dmarc.example.domain.com. TXT “v=DMARC1; p=none;”
- Root domain: _dmarc.domain.com. TXT “v=DMARC1; p=none;”
- Note that ALL From Domains which you use in the From address field of your emails must have a DMARC record like above. For reference, in the example above, the From address in the email would look like: acoustic@example.domain.com.
- If you want reports emailed to your organization, enter the following DMARC record instead: “v=DMARC1; p=none; fo=1=; rua=mailto:dmarc_rua@yourdomain.com; ruf=mailto:dmarc_ruf@yourdomain.com”
- You should complete this activity before February 2024, in order to meet Gmail’s minimum standards.
For Acoustic hosted domains:
- Acoustic will add a DMARC record into your DNS, if you don’t already have one.
- At minimum, we will add : ‘v=DMARC1; p=none;’
- If you already have a DMARC record in place, we will not make any changes.
- If you want reports emailed to your organization, enter a support case with the email address you want the reports emailed to.
- Acoustic will complete this activity before February 2024, in order to meet Gmail’s minimum standards.
Note: You can review and update the DMARC settings by accessing the DMARC setting page for your domain from the three-dot menu > DMARC settings.
For shared domains & Acoustic domains:
- If you are sharing domains with multiple brands, a DMARC record is still required. When setting the record, ensure that you validate the DMARC process with those brands prior to setting any policy higher than p=none.
- How will Acoustic domains be handled?
Acoustic has provided shared domains on rare occasions, typically for testing purposes and demo purposes. These domains are managed by Acoustic and will have a DMARC policy of p=none established. If you are using an Acoustic shared domain for production emails, and wish to setup a stricter DMARC policy, you will need to identify a custom sub-domain to migrate to with your IT or domain provider and open a Provisioning ticket to request the custom domain configuration. Contact your Client Success Manager for assistance with setting up a new domain and review this guide.
Acoustic DMARC recommendations
Gradual policy deployment
- https://support.google.com/a/answer/10032169?sjid=7851110637213840929-NA
- Start with a “None” Policy (p=none):
- Begin by publishing a DMARC record with a policy of “none” (p=none) for your domain. This policy instructs receiving email servers to send you DMARC reports without taking any action on the email. It allows you to collect data on how your legitimate and fraudulent emails are being handled.
- Monitor DMARC reports:
- Begin monitoring the DMARC aggregate (RUA) reports that you receive. These reports will provide insights into how your domain is being used for email and which sources are sending emails on your behalf.
- Gradually analyze reports:
- Over time, analyze the DMARC reports to identify sources of legitimate email (e.g., your own email servers, authorized third-party services) and sources of unauthorized or suspicious email (e.g., phishing attempts, spoofed emails).
- Identify legitimate senders:
- Identify all legitimate sources that send email on behalf of your domain. This includes your own email servers, marketing automation platforms, third-party email services, and any other authorized senders.
- Implement SPF and DKIM:
- Ensure that all legitimate sources sending email on behalf of your domain have proper SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) configurations in place. This involves creating DNS records for SPF and DKIM, which specify the authorized email servers and cryptographic keys for your domain.
- If you are using From domains on the Acoustic platform which you own and are not yet configured with SPF/DKIM/etc, then you can open a case with Provisioning to enable your domain as a sending domain or a full custom sending domain.
- Gradually change the DMARC policy to “Quarantine” (p=quarantine):
- Once you are confident that all legitimate sources are correctly configured with SPF and DKIM and your DMARC reports show a minimal number of legitimate emails failing authentication, you can change your DMARC policy to “quarantine” (p=quarantine). This instructs receiving servers to place emails that fail DMARC checks into the recipient’s spam or quarantine folder.
- Continue monitoring and fine-tuning:
- Keep monitoring your DMARC reports after transitioning to a “quarantine” policy. Review any issues that may arise and continue to fine-tune your SPF and DKIM configurations as necessary.
- Transition to “Reject” policy (p=reject):
- Once you have successfully managed the “quarantine” policy for a while and are confident in the accuracy of your authentication mechanisms and email sources, you can consider transitioning to a “reject” (p=reject) policy. This policy instructs receiving servers to reject emails that fail DMARC authentication outright.
Consulting
For additional consulting around DMARC, contact your CSD or CSM for more information.