Technical Aspects
Sending infrastructure and Reputation
Sending infrastructure and reputation are crucial to ensuring that emails reach the inbox and do not end up in spam.
- Sending infrastructure: A well-configured mail server reduces the risk of spoofing and increases deliverability.
- Reputation: Refers to the score assigned by ISPs (and filtering systems) to a specific email flow and is the sum of the reputation of all identifiable components within a message (IP, domains, URLs, etc.).
To simplify, reputation is the reliability rating that an ISP assigns to a sender.
Professional sending platforms, such as Contactlab, comply with security standards, have IPs listed in the most reputable international allow-lists, and ensure a high email delivery rate, while also supporting the sending of large volumes of messages over time.
Sender authentication protocols
There are several methods and protocols of authentication that allow email providers and end users to verify the identity of a sender and reduce the risk of spam and phishing.
Authenticating emails with SPF, DKIM, and DMARC was already highly recommended, but since 2024, it has become essential for those sending bulk emails. Gmail and Yahoo have made these protocols mandatory for message delivery, and starting in May 2025, Microsoft will adopt the same rules.
SPF (Sender Policy Framework)
It is a security mechanism that helps prevent spoofing (falsification of the sender's address) and the receipt of phishing emails.
It allows the owner of a domain to specify which servers (IP addresses) are authorized to send emails on behalf of that domain. This is done through a record in the domain's DNS.
When a mail server receives an email, it checks the SPF record of the sender's domain to verify if the IP of the server that sent the email is authorized. If it is not, the email may be flagged as suspicious or rejected.
Domains used to send via Send or CDP should always include Contactlab's IPs in the SPF:
- v=spf1 → Indicates the SPF version.
- include:t.contactlab.it → Allows Contactlab's servers to send emails for this domain.
- -all → Indicates that emails from servers not listed should be rejected.
DKIM (DomainKeys Identified Mail)
It is an authentication protocol that helps verify that an email has not been altered during transit and that it genuinely comes from the declared domain.
To do this, it uses public and private key encryption:
- The sender digitally signs the email using a private key.
- The recipient verifies the signature by comparing it with the public key, which is published in the sender's domain DNS records.
If the signature is valid, it means that the email has not been modified and indeed comes from an authorized server.
A DKIM record in DNS might look like this:
- v=DKIM1 → Indicates the DKIM version.
- k=rsa → Specifies the encryption algorithm used.
- p=MIGfMA0GCSq... → Contains the public key.
To send with DKIM signature from Contactsend and CDP, it is enough to delegate a third-level domain (e.g., @news.yourdomain.com) to Contactlab, which will take care of completing the configurations. You can continue sending with the second-level domain, which will inherit the DKIM for parent from the delegated subdomain.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
It is an authentication protocol based on SPF and DKIM that allows a domain owner to define how recipient mail servers should handle emails that fail SPF and DKIM checks.
When an email arrives, the recipient server checks:
- Whether it passes SPF and/or DKIM.
- Whether the sender domain aligns with the SPF/DKIM records.
- What to do if the email fails the checks, based on the DMARC policy set (accept, quarantine, or reject).
A DMARC record in DNS looks like this:
- v=DMARC1 → Indicates the protocol version.
- p=quarantine → Sets the policy (can be none, quarantine, or reject).
- rua=mailto:
report@yourdomain.com→ Specifies the email address where reports about domain abuse attempts will be sent.
Available DMARC policies:
- none → Monitors emails, sends reports but takes no action.
- quarantine → Flags suspicious emails as spam or places them in quarantine.
- reject → Directly rejects non-compliant emails (they won’t be delivered to inbox or spam).
DMARC can be configured independently or with Contactlab Support. DMARC configuration is always carried out by Contactlab in the case of a third-level domain delegation.
If configuring DMARC independently, make sure that DKIM has been correctly set up in Contactlab before applying restrictive policies (quarantine or reject), or messages will end up in spam or won’t be delivered at all.
Brand identity
Working on the consistency, identity, and recognizability of your brand brings numerous benefits in terms of:
- sender (and company) reputation;
- reduced spam complaints and improved deliverability;
- company transparency and brand trust.
For this reason, it's important to also customize the message headers and links so that everything is aligned with the brand.
By subscribing a Brand Shield, Contactlab will, by default, configure DKIM, DMARC, customize the envelope from, and tracking links.
Esempio:
In the header above, we can see how:
- envelope from
- mail from
- reply to
- authentication systems
- link tracking
all refer to the same domain.
Envelope From
The Envelope From (or Return-Path) is the address that identifies the server/service that sent the message. It may differ from the sender's address as well as from the reply-to address.
The receiving server uses the Envelope From to send bounce notifications (non-delivery reports).
It can be found in the message header, identified by the Return-Path line.
Default Envelope From:
Custom Envelope From:
Custom tracking
Custom tracking refers to branded link tracking that removes any reference to Contactlab and uses a domain associated with the brand.
Example of default tracking:
Example of custom tracking:
If multiple sender domains are used, only one domain per platform can be configured with a custom envelope from and tracking.