SPF, DMARC, and Compliance Addresses
To meet the main specifications of email services, the following guidelines should be followed. It is recommended that every email service have the following settings:
- A TXT key in the DNS for SPF, which will allow sending messages from certain servers. Example lines are as follows:
"v=spf1 include:_spf.google.com -all" "v=spf1 include:spf.protection.outlook.com -all"
- A DKIM configuration, used by the email server that will authenticate the messages to be sent, which can vary between a TXT or CNAME key depending on the email service strategy
- A DMARC configuration, which will declare the rule adopted for the SPF and DKIM records. The following value is recommended, changing the email address that will receive the DKIM result reports:
"v=DMARC1; p=reject; sp=reject; fo=1; adkim=r; aspf=r; pct=100; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; rf=afrf; ri=86400;"
- If the emails presented to receive the DMARC reports are not from the same domain as the rule, a TXT key is required in the subdomain
*._report._dmarcor (the email domain instead of the wildcard *, for example:example.com._report._dmarc):
"v=DMARC1;"
- Email groups or distribution lists with the following IDs:
abuse (contact about email service abuse) admin (administrator contact - not documented in RFC) administrator (administrator contact - not documented in RFC) hostmaster (contact about domain zone issues) noc (contact about network infrastructure issues) postmaster (contact about email infrastructure issues) security (contact about security issues) webmaster (contact about websites)
Google Workspace Forwarding Strategy:
It is recommended to forward all other administrative mailboxes to a group named security@ using the routing feature found in Apps > Google Workspace > Settings for Gmail > Routing (link), since Google reserves some email addresses such as abuse@, preventing them from being added as aliases. Google allows external addresses and groups to be members of local groups; if necessary, you can add the external contact directly to the group.
For forwarding individual mailboxes to external recipients, if forwarding is blocked, it is necessary to create a new OU with forwarding permission granted to perform external forwarding for that user. Check the Automatic forwarding settings here.
Microsoft 365 Forwarding Strategy:
It is recommended to forward all other administrative mailboxes to a group named security@ through an alias on the group itself. Microsoft allows external addresses and groups to be members of local groups as long as they are added as contacts. If necessary, add the external contact on the platform under Users > Contacts (link) and add this contact as a group member.
For forwarding individual mailboxes to external recipients, blocking is enabled by default. You can configure a policy via PowerShell to allow the specified local account to forward messages to external recipients using the following lines:
Connect-ExchangeOnline
Get-HostedOutboundSpamFilterPolicy
New-HostedOutboundSpamFilterPolicy -Name "Allow Specific Forwarding" -AutoForwardingMode On
New-HostedOutboundSpamFilterRule -Name "Allow Specific Forwarding Rule" -HostedOutboundSpamFilterPolicy "Allow Specific Forwarding" -From "localaccount@domain.example"Forwarding rules can also be checked here, however, creating them via PowerShell is recommended to avoid creation failures.
Locaweb Strategy:
The provider is inconsistent regarding sending messages from groups. It is recommended to create a mailbox named security@, add aliases with other alternatives, and add a rule through the webmail to forward messages to the desired contact, which can be internal or external.
Mailboxes for Services:
It is recommended to use different records or mailboxes with subaddressing when using them in contact records such as CAA, DMARC, security.txt, SOA, for example:
caa@ or security+caa@ for CAA type record dmarc@ or security+dmarc@ for TXT record of host "_dmarc" security.txt@ or security+security.txt@ for security.txt contact record soa@ or security+soa@ for SOA type record
Additional Information:
Domain monitoring and reputation services are also recommended, such as Postmaster Tools offered by the Google Gmail platform.
Domains without email service should use MX with invalid hostname 0 . and SPF without approvals "v=spf1 -all", along with the appropriate DMARC rules to prevent spoofing attacks using these domains.