Starting February 1, 2024, Google and Yahoo are rolling out changes for senders who send more than 5,000 messages per day to Gmail accounts. Other major email service providers such as Microsoft are expected to join soon.
This basically does not apply to WEDOS customers using web hosting services (LowCost, NoLimit, NoLimit Extra), Mailhosting and WMS.
It is completely forbidden to send any bulk emails via web hosting, regardless of whether the messages are solicited or not. Therefore, it is not even allowed to send out various newsletters to registered subscribers. If the customer needs to send bulk emails, they have to find another tool, for example by setting up their own mailservers using VPS or a dedicated server. If you are using bulk messaging services to send, we’ll show you what changes Google is planning.
Messages sent to our customers, such as our newsletters, information, invitations, but also invoicing, notifications and more, are already prepared for this change.
Updated settings for sending bulk emails to Google
Starting February 1, 2024, if you send more than 5,000 messages per day to private e-mail addresses ending with @gmail.com or @googlemail.com, Google will require not only the correct configuration of SPF and DKIM, but also the implementation of DMARC .
This is a measure against fraudulent emails.
- SPF determines which servers are allowed to send email on behalf of a domain.
- DKIM adds another layer of authentication to sent emails by confirming their origin.
- DMARC then uses SPF and DKIM to determine the procedures that should be followed if authentication using SPF or DKIM fails.
On our web hosting and mail hosting, we use our own WEDOS domain for digital email signing (DKIM), instead of the domain of the person sending the email. This still ensures that the email is properly signed and verifiable, which increases its credibility and helps prevent it from being marked as spam.
SPF, DKIM and DMARC in detail
SPF (Sender Policy Framework) is an email authentication system that allows domain owners to specify which servers are allowed to send email on behalf of their domain. Recipients can then verify SPF records and decide whether to accept, reject, or otherwise process the email.
DKIM (DomainKeys Identified Mail) is a method that allows the organization responsible for sending the email to attach a digital signature to the message. Recipients can verify this signature and confirm that the email has not been altered after sending and that it is from a legitimate source.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication policy and reporting protocol that helps protect email domains from abuse such as phishing and spoofing. DMARC uses SPF and DKIM to verify that outgoing emails are legitimate and defines how the recipient should deal with emails that fail verification.
DMARC settings
DMARC is a special TXT record. You simply set it up according to the instructions from our knowledge base.
If DMARC is to apply to the “main” domain (domain.tld), it is set as a 3rd-level domain named _dmarc (ie _dmarc.domain.tld).
If it is to apply to a subdomain (e.g. sub.domain.tld), it will be set as the 4th order domain of the _dmarc.subdomain (e.g. _dmarc.sub.domain.tld). We will show detailed examples below.
According to information from the official Google website, it is fully sufficient to set DMARC in this basic form:
v=DMARC1; p=none; rua=mailto:vas-email@domena.tldDMARC setup in WEDOS DNS
In the Name field, type _dmarc (in the case of using the main domain), in the case of using a 3rd-order domain (subdomain), type _dmarc.sub (replace sub with the name of your subdomain).
In the Data field, we insert the DMARC parameters of your choice, for example v=DMARC1; p=none; rua=mailto:your-email@domain.tld.
DMARC record parameters
A DMARC record contains several key parameters that are separated by a semicolon and a space, and begins with the version identifier v=DMARC1;.
This initial identification is followed by a number of other parameters that specify the details of the DMARC policy and its behavior, such as the policy for responding to emails that fail authentication (e.g. p=none, p=quarantine or p=reject), the reporting frequency (rua for Aggregation Report Address, ruf for Forensic Data Report Address), percentage of messages covered by policy (pct), and other guidelines for email authentication processing and reporting.
These parameters allow organizations to set up and customize their email fraud and abuse protection.
| Parameter | Description | Values |
| p | Defines the action to be taken by the recipient if the email fails DMARC validation. | none – no action, only reporting; quarantine – possible marking as spam; reject – the message will be rejected |
| sp | Specific DMARC policy for subdomains. | same as p |
| rua | Address for sending summary reports, providing an overview of e-mail communications. | mailto:mail@domain.tld |
| ri | Time interval in seconds for regular sending of summary reports. | positive integer |
| ruf | Address for sending detailed forensic reports on individual e-mails. | mailto:mail@domain.tld |
| fo | Specifies when forensic reports should be generated. | 0 – only when both SPF and DKIM fail; 1 – when both SPF and DKIM fail; d – only when DKIM fails; s – only when SPF fails |
| pct | Sets the percentage of emails to be verified. | positive integer, up to 100 |
| adkim | Specifies the rules for verifying the domain match in the DKIM signature. | r (relaxed) – allows matching of the main domain and its subdomains; s (strict) – requires an exact domain match |
| aspf | Defines the rules for verifying the domain match in an SPF record. | same as adkim |
Examples of parameters in a DMARC record
v=DMARC1; p=none – messages are delivered without intervention, reporting is not performed.
v=DMARC1; p=quarantine; [rua=mailto:dmarc@domain.tld](<mailto:rua=mailto:dmarc@domain.tld>); ri=86400 – if the message does not pass DMARC verification, it is classified as spam. Aggregated reports are sent to dmarc@domena.tld at most once a day.
v=DMARC1; p=reject; rua=mailto:[dmarc@domain.tld](<mailto:dmarc@domain.tld>); ruf=mailto:[dmarc@domain.tld](<mailto:dmarc@domain.tld>); adkim=s; aspf=s – email is rejected if DMARC verification fails. Address dmarc@domain.tld accepts both aggregated and detailed reports. DKIM and SPF authentication are set to strict mode.