MX Record
When adding a domain to send email campaigns from your mail hoster, please, be careful with the priority of MX records.
If you will put our record before your mailboxes hoster (for ex. Google), then our mail server will intercept all incoming emails and they won’t be delivered. It’s better to put this record just after the last prioritized MX record, so then, our mail server will deliver successfully and won’t intercept emails sent to you.
The priority number can be from 0 to 65535, and processing starts from 0, which means 10 will be processed earlier than 100. That’s why you’ll need to put the priority “higher” than others for the MX record, with value mail.creabl.com.
SPF Record
Mechanisms can be prefixed with one of four qualifiers:
"+" Pass
"-" Fail
"~" SoftFail
"?" Neutral
If a mechanism results in a hit, its qualifier value is used. The default qualifier is "+", i.e. "Pass". For example:
"v=spf1 -all"
"v=spf1 a -all"
"v=spf1 a mx -all"
"v=spf1 +a +mx -all"
Mechanisms are evaluated in order. If no mechanism or modifier matches, the default result is "Neutral".
If a domain has no SPF record at all, the result is "None". If a domain has a temporary error during DNS processing, you get the result "TempError" (called "error" in earlier drafts). If some kind of syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is "PermError" (formerly "unknown").
Evaluation of an SPF record can return any of these results:
For example, you already have SPF record for Gmail with value:
v=spf1 include:_spf.google.com ~all
In this case you’ll need to add “mx” before “~all” to pass validation in our product. Also, feel free to ask for help if you are experiencing issues.
DMARC Record
DMARC is designed to fit into an organization’s existing inbound email authentication process. The way it works is to help email receivers determine if the purported message “aligns” with what the receiver knows about the sender. If not, DMARC includes guidance on how to handle the “non-aligned” messages. For example, assuming that a receiver deploys SPF and DKIM, plus its own spam filters, the flow may look something like this:
For example, you already have _dmarc record with “rua” or/and others tags, something like “v=DMARC1; p=none; rua=mailto:xxx”. In this case our product will validate records without any issues.
Anatomy of a DMARC resource record in the DNS
DMARC policies are published in the DNS as text (TXT) resource records (RR) and announce what an email receiver should do with non-aligned mail it receives.
Consider an example DMARC TXT RR for the domain “sender.dmarcdomain.com” that reads:
"v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com"
In this example, the sender requests that the receiver outright reject all non-aligned messages and send a report, in a specified aggregate format, about the rejections to a specified address. If the sender was testing its configuration, it could replace “reject” with “quarantine” which would tell the receiver they shouldn’t necessarily reject the message, but consider quarantining it.
DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
DKIM Record
DomainKeys Identified Mail (DKIM) is a method of email authentication that helps prevent spammers and other malicious parties from impersonating a legitimate domain.
All email addresses have a domain — the part of the address after the "@" symbol. Spammers and attackers may try to impersonate a domain when sending emails to carry out phishing attacks or other scams.
How does DKIM work?
There are two main aspects of DKIM: the DKIM record, which is stored in the Domain Name System (DNS) records for the domain, and the DKIM header, which is attached to all emails from the domain.
DKIM uses digital signature schemes based on public key cryptography to authenticate where an email came from, that it actually came from a server that sends emails from that domain. A pair of cryptographic keys are used: a private key for the sender to sign messages, and a public key for the receiver to verify signatures. A receiver cannot use the public key to sign messages, and vice versa.
The email provider generates the public key and private key. They give the public key to the domain owner, who stores the public key in a publicly available DNS record — the DKIM record.
All emails sent from that domain include a DKIM header, which contains a section of data that is signed with the private key: this is called a "digital signature." An email server can check the DKIM DNS record, obtain the public key, and use the public key to verify the digital signature.
This process also ensures that the email has not been changed in transit. The digital signature will not be verified if email headers or the email body have been altered — like a tamper-proof seal on a canister of medicine.