The DMARC (Domain-based Message Authentication, Reporting & Conformance) protocol is an email validation tool designed to protect domains from unauthorized use, including phishing and email spoofing. It aligns SPF and DKIM authentication methods to verify the sender’s identity and provide reports on email delivery. Additionally, it allows you to specify what happens to outgoing messages from your organization that do not pass SPF or DKIM.

The DMARC protocol is now required by Gmail and Yahoo and so, it became obligatory for SALESmanago customers. Read the article below and configure the DMARC protocol for your domain to maintain your ability to send emails to @gmail.com and @yahoo.com addresses.

IMPORTANT: Remember to implement SPF and DKIM before implementing DMARC. All these protocols are currently required by Gmail and Yahoo. Additionally, without DKIM, DMARC will not work correctly.

---

Contents

1. Getting started
2. Quick summary: DMARC configuration recommended by SALESmanago
3. Implementing the DMARC protocol for your domain
   1. Step 1. Determine where you can edit your DNS settings
   2. Step 2. Find the right place in the DNS settings
   3. Step 3. Configure the DKIM protocol
4. APPENDIX: DMARC record elements

---

1. Getting started

The new Gmail and Yahoo requirements >> imposed on bulk (mass) email senders are likely to apply to SALESmanago customers who:

• use a SALESmanago Email Marketing sender account, or
• use an External (SMTP) sender account and send (regularly or occasionally) more than 5,000 emails a day.

To make sure that these new requirements do not affect the deliverability of its customers, SALESmanago has made the implementation of SPF, DKIM, and DMARC obligatory. The instructions below will guide you through the process of implementing the DMARC protocol.

---

2. Quick summary: DMARC configuration recommended by SALESmanago

The table below sums up the DNS entry for DMARC recommended by SALESmanago.

Remember that the details marked in green are just placeholders and must be replaced with your own data.

Protocol	Name	Type	Value	TTL
DMARC	_dmarc.example.com	TXT	v=DMARC1; p=quarantine; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcreports@example.com; adkim=r; aspf=r;	3600

---

3. Implementing the DMARC protocol for your domain

The DMARC protocol is usually implemented in the DNS (Domain Name System) settings for your domain.

IMPORTANT:

• The instructions below are of a generic nature. The actual process may look different depending on the eCommerce platform, domain registrar, hosting provider, or CDN provider whose services you use.
• Before implementing the DMARC protocol, make sure that you don’t have it in place already. You will probably be able to check this in the same control/user/configuration panel where you can add a new record – simply review the list of existing records.

---

Step 1. Determine where you can edit your DNS settings

Depending on the way in which your website is set up, consider these four possibilities:

• E-store set up on a SaaS eCommerce platform (such as Shopify or BigCommerce): Log in to your e-store account and search for DNS settings. For instance, on Shopify, you need to go to Settings → Domains → Domain settings → Edit DNS settings.
• Domain purchased via a hosting provider (such as OVH or A2 Hosting): Log in to your hosting account and go to the control panel (which can be called “user panel”, “domain configuration panel”, etc).
• Domain purchased via a domain registrar (such as GoDaddy or OVH): Log in to your domain account and go to the control panel (which can be called “user panel”, “domain configuration panel”, etc).
• Website served via a Content Delivery Network—CDN (such as Cloudflare): Log in to your CDN account and go to the control panel (which can be called “user panel”, “domain configuration panel”, etc).

In Cloudflare, go to DNS → Records:

Read more about managing DNS records in Cloudflare >>

NOTE: If you have more than one domain, make sure to select the one you want to configure.

---

Step 2. Find the right place in the DNS settings

After logging into the account that allows you to edit your DNS settings, look for the place where you can add records for your domain. This place (section, tab, etc.) can be called, for instance, DNS Settings, Zone Editor, DNS Management, Name Server Configuration, or DNS Record Management.

It is possible that you will see buttons like Add TXT record and Add CNAME record; or you may need to click a button for adding a record and then select the record type from a list. If you can’t find the option to add a record for your domain, consult the help materials of your service provider (eCommerce platform, domain registrar, hosting provider, or CDN provider) or contact their customer support.

---

Step 3. Configure the DMARC protocol

Add a TXT record for your domain.

You will probably see a number of input fields that allow you to define the new record. Pay attention to these three fields:

• Host (Host record, Host name, Name, Domain, etc.)—In this field, enter the following value:

_dmarc.example.com

Remember to replace the fragment highlighted in green with your own email sending domain.

EXAMPLES:

_dmarc.yourcompany.com

_dmarc.yourstore.de

_dmarc.yourecommerce.es

TIPS:

• After completing the Host field, you may see that a dot (full stop) was added at its end. Don’t try to delete it—this is a required formatting element.
• If you are in doubt which field is the Host field, look at your existing records and check which field contains domain addresses.

• Text value (Main value, Record, Value, Content, etc.)—In this field, enter your DMARC record (see the Appendix below for a description of its elements). If you are unsure which parameters and values you should use for your DMARC record, consider using the format recommended by SALESmanago.

Copy this formula and paste it into the main input field of the new TXT record, replacing the details highlighted in green with your own data:

• The rua parameter is the address at which you will receive aggregate reports on your email traffic.
• Ruf is the address at which you will receive reports on failed authentication checks. Note that this parameter is not supported by Gmail.
• As the number of DMARC reports can be very high, consider creating separate inboxes for these reports.

EXAMPLES:

(1) v=DMARC1; p=quarantine; rua=mailto:emailmanager@company.com;
ruf=mailto:emailfailures@company.com; adkim=r; aspf=r;

(2) v=DMARC1; p=quarantine; rua=mailto:administrator@yourcompany.de;
ruf=mailto:dmarcfailures@yourcompany.de; adkim=r; aspf=r;

You can also customize individual values based on the parameters (tags) and definitions set out in the table provided in the Appendix.

• TTL (Time to Live)—We recommend setting the TTL (Time to Live) to 1 hour (3600 seconds).

After completing these three fields, add the ready record by clicking Save, OK, Done, etc. You don’t need to take any additional steps on the SALESmanago platform.

IMPORTANT: The DMARC protocol will be implemented for your domain within several hours, but it can take up to 24 hours for the changes to become visible in your domain settings (due to a DNS propagation delay).

If you have any questions or doubts concerning the configuration of your email authentication protocols, or if you would like to have your setup verified by our Support specialist, please contact us at: support@salesmanago.com

---

4. APPENDIX: DMARC record elements

The table below presents parameters (tags) and values for DMARC records, as described in the Google Help Center article >>

IMPORTANT:

• Setting the aspf parameter to a value other than “r” will result in DMARC failure. Thus, we recommend including the following tags: aspf=r; adkim=r; in the record formula.
• If you are unsure which values you should use for your DMARC record, consider using the recommended SALESmanago format (see Section 3.C. above).

Tag	Description and values
v	DMARC version. Must be DMARC1. This tag is required.
p	Instructs the receiving mail server what to do with messages that don’t pass authentication. none—Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the record. quarantine—Mark the messages as spam and send it to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages. reject—Reject the message. With this option, the receiving server usually sends a bounce message to the sending server. This tag is required. BIMI note: If your domain uses BIMI, the DMARC p option must be set to quarantine or reject. BIMI doesn’t support DMARC policies with the p option set to none.
pct	Specifies the percent of unauthenticated messages that are subject to the DMARC policy. When you gradually deploy DMARC, you might start with a small percentage of your messages. As more messages from your domain pass authentication with receiving servers, update your record with a higher percentage, until you reach 100 percent. Must be a whole number from 1 to 100. If you don’t use this option in the record, your DMARC policy applies to 100% of messages sent from your domain. This tag is optional. BIMI note: If your domain uses BIMI, your DMARC policy must have a pct value of 100. BIMI doesn’t support DMARC policies with the pct value set to less than 100.
rua	Email address to receive reports about DMARC activity for your domain. The email address must include mailto: For example: mailto:dmarc-reports@solarmora.com To send DMARC reports to multiple emails, separate each email address with a comma and add the mailto: prefix before each address. For example: mailto:dmarc-reports@solarmora.com, mailto:dmarc-admin@solarmora.com This option can potentially result in a high volume of report emails. We don’t recommend using your own email address. Instead, consider using a dedicated mailbox, a group, or a third-party service that specializes in DMARC reports. This tag is optional.
ruf	Not supported. Gmail doesn’t support the ruf tag, which is used to send failure reports. Failure reports are also called forensic reports.
sp	Sets the policy for messages from subdomains of your primary domain. Use this option if you want to use a different DMARC policy for your subdomains. none—Take no action on the message and deliver it to the intended recipient. Log messages in a daily report. The report is sent to the email address specified with the rua option in the policy. quarantine—Mark the messages as spam and send it to the recipient’s spam folder. Recipients can review spam messages to identify legitimate messages. reject—Reject the message. With this option, the receiving server should send a bounce message to the sending server. If you don’t use this option in the record, subdomains inherit the DMARC policy set for the parent domain. This tag is optional.
adkim	Sets the alignment policy for DKIM, which defines how strictly message information must match DKIM signatures. s—Strict alignment. The sender domain name must exactly match the corresponding d=domainname in the DKIM mail headers. r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of d=domain in the DKIM mail headers is accepted. This tag is optional.
aspf	Sets the alignment policy for SPF, which specifies how strictly message information must match SPF signatures. s—Strict alignment. The message From: header must exactly match the domain name in the SMTP MAIL FROM command. r—Relaxed alignment (default). Allows partial matches. Any valid subdomain of domain name is accepted. This tag is optional.

Source: Google Help Center >>