In this example, the “Sender” mt.kb.user@gmail.com wants to send an email to the “Receiver” user@example.com. The sender composes the email at gmail.com, and user@example.com receives it in the email client Apple Mail.

Here is the example header:

From: Media Temple user (mt.kb.user@gmail.com)
Subject: article: How to Trace a Email
Date: January 25, 2011 3:30:58 PM PDT
To: user@example.com
Return-Path: <mt.kb.user@gmail.com>
Envelope-To: user@example.com
Delivery-Date: Tue, 25 Jan 2011 15:31:01 -0700
Received: from po-out-1718.google.com ([]:54907) by cl35.gs01.gridserver.com with esmtp (Exim 4.63) (envelope-from <mt.kb.user@gmail.com>) id 1KDoNH-0000f0-RL for user@example.com; Tue, 25 Jan 2011 15:31:01 -0700
Received: by po-out-1718.google.com with SMTP id y22so795146pof.4 for <user@example.com>; Tue, 25 Jan 2011 15:30:58 -0700 (PDT)
Received: by with SMTP id t17mr3929916rvm.251.1214951458741; Tue, 25 Jan 2011 15:30:58 -0700 (PDT)
Received: by with HTTP; Tue, 25 Jan 2011 15:30:58 -0700 (PDT)
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+JqkmVt+sHDFIGX5jKp3oP18LQf10VQjAmZAKl1lspY=; b=F87jySDZnMayyitVxLdHcQNL073DytKRyrRh84GNsI24IRNakn0oOfrC2luliNvdea LGTk3adIrzt+N96GyMseWz8T9xE6O/sAI16db48q4Iqkd7uOiDvFsvS3CUQlNhybNw8m CH/o8eELTN0zbSbn5Trp0dkRYXhMX8FTAwrH0=
Domainkey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=wkbBj0M8NCUlboI6idKooejg0sL2ms7fDPe1tHUkR9Ht0qr5lAJX4q9PMVJeyjWalH 36n4qGLtC2euBJY070bVra8IBB9FeDEW9C35BC1vuPT5XyucCm0hulbE86+uiUTXCkaB 6ykquzQGCer7xPAcMJqVfXDkHo3H61HM9oCQM=
Message-Id: <c8f49cec0807011530k11196ad4p7cb4b9420f2ae752@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary=”—-=_Part_3927_12044027.1214951458678″
X-Spam-Status: score=3.7 tests=DNS_FROM_RFC_POST, HTML_00_10, HTML_MESSAGE, HTML_SHORT_LENGTH version=3.1.7
X-Spam-Level: ***
Message Body: This is a KnowledgeBase article that provides information on how to find email headers and use the data to trace a email.



It is important to know that when reading an email header every line can be forged, so only the Received: lines that are created by your service or computer should be completely trusted.


  • This displays who the message is from, however, this can be easily forged and can be the least reliable.


  • This is what the sender placed as a topic of the email content.


  • This shows the date and time the email message was composed.


  • This shows to whom the message was addressed, but may not contain the recipient’s address.


  • The email address for return mail. This is the same as “Reply-To:”.


  • This header shows that this email was delivered to the mailbox of a subscriber whose email address is user@example.com.

Delivery Date

  • This shows the date and time at which the email was received by your (mt) service or email client.


  • The received is the most important part of the email header and is usually the most reliable. They form a list of all the servers/computers through which the message traveled in order to reach you.The received lines are best read from bottom to top. That is, the first “Received:” line is your own system or mail server. The last “Received:” line is where the mail originated. Each mail system has their own style of “Received:” line. A “Received:” line typically identifies the machine that received the mail and the machine from which the mail was received.

Dkim-Signature & Domainkey-Signature


  • A unique string assigned by the mail system when the message is first created. These can easily be forged.



  • Generally, this will tell you the format of the message, such as html or plaintext.


  • Displays a spam score created by your service or mail client.


  • Displays a spam score usually created by your service or mail client.

Message Body

  • This is the actual content of the email itself, written by the sender.


The easiest way for finding the original sender is by looking for the X-Originating-IP header. This header is important since it tells you the IP address of the computer that had sent the email. If you cannot find the X-Originating-IP header, then you will have to sift through the Received headers to find the sender’s IP address. In the example above, the originating IP Address is

Once the email sender’s IP address is found, you can search for it at http://www.arin.net/. You should now be given results letting you know to which ISP (Internet Service Provider) or webhost the IP address belongs. Now, if you are tracking a spam email, you can send a complaint to the owner of the originating IP address. Be sure to include all the headers of the email when filing a complaint.

Run script with jenkins as root

create the script with jenkins group : /pathtoscript.sh

vim /etc/sudoers

add the following row to the conf sudoers file

jenkins    ALL=(ALL)  NOPASSWD: /pathtoscript.sh

be carefull only root can read write execute , jenkins can read and execute not write

chmod 750 /pathtoscript.sh


SPF Permerror

A majority of organizations use multiple email service providers and every single one of them requires their own email authentication tools. If your email service provider supports SPF, you will need to include their SPF mechanism in your own SPF record.


However, you can run into errors which can result in the non-delivery of your emails. One such error is the SPF Permerror. Today, we will show you how to fix an SPF permerror so your SMTP is secured.

What is an SPF Permerror?

An SPF permerror or ‘SPF Permanent Error’ is one of the most common SPF errors that comes up when the domain’s SPF record could not be properly interpreted resulting in the non-delivery of emails.

An SPF Permerror can occur due to these reasons:

  • If the SPF record has a syntax error
  • If a domain has multiple SPF records
  • If the SPF evaluates more than 10 DNS mechanism lookups in an SPF record

What Is SPF Permerror – “Too Many DNS Lookups”?

This is the most common error out of the three types of SPF permerror. SPF has put several safeguards in place to make sure that you do not have any timeouts issues. An SPF will evaluate 10 DNS mechanisms in an SPF record. They include: a, mx, ptr, exists, include, redirect. If these DNS records exceed more than 10, it will raise an SPF Permerror. When an SPF permerror is raised, you will have to remove a few lookups/mechanisms.

What Does SPF Validation Failed Mean?

An SPF validation error comes up when the Sender Policy Framework (SPF) validation for the sender’s domain is not successful. To prevent these issues, an email admin should make sure that their domain for the domain registrar is set up properly. These are some common reasons an SPF validation error takes place:

  • Multiple SPF Records
  • SPF Validation is Not Available
  • More than 10 DNS Lookups
  • PTR Mechanism Usage
  • Macro is Invalid
  • Multiple Fallback Scenarios

A warning SPF validation failed will be given if your SPF record is not set properly. You can check invalid SPF record examples here.

Office 365 SPF Permerror

To prevent spoofing and get great email delivery, it is advisable to set up SPF in Microsoft (News – Alert) Office 365. To avoid SPF Permerror Office 365, you can go through these points.

  • Only one SPF record is enough for your domain
  • If you have a subdomain, create separate records
  • To avoid getting a permerror, make sure the there are no DNS lookups over 10

An Office 365 SPF permerror can be avoided by following these points. An SPF error such as the SPF permerror and SPF temperror can give you a huge problem for delivering your emails. This way you won’t have any deliverability issues.

How to Fix An SPF Permerror?

SPF Flattening

SPF flattening is a process to flatten order of an SPF record to a flattened record that contains less than 10 DNS lookups/mechanisms. It is also called an SPF record compression. By using a flattened SPF record, you can flatten the number of DNS querying mechanisms/lookups to 1.

The SPF flattening works by removing the ‘a,’ ‘mx,’ and ‘include’ mechanisms to make a simplified SPF record and reduces the amount of DNS lookups. Without doing this, there will be an unnecessary amount of DNS lookups.

Other mechanisms such as ip4 and ip6 are added as they do not use any SPF lookups.

Avoiding Unnecessary ‘include’ Statements

An ‘include’ statement is a mechanism that is used to redirect the DNS lookup to verify authorized IPs of another domain’s SPF record. These ‘include’ statements in the original SPF records will count towards the limit of 10.

Removing Reference to Invalid and Unused Domains

If a domain is unused by you or your partner’s vendor then any ‘include’ statements that redirect the SPF check to a domain. To reduce the number of DNS lookups, you should always make sure that any inactive domains in your SPF record should be removed.

You can also use these methods to avoid an SPF permerror:

  • Replacing the ‘include’ statement with ip4 and ip6 mechanisms when possible
  • You can remove mechanisms that refer to the same domain
  • Limit the use of PTR mechanisms as its usage can result in numerous DNS lookups
  • Use SPF record checks

You can also know more by referring to the SPF FAQs.

Handling Forged Emails Using SPF

Scammers and spammers forge a lot of emails by using numerous domains and email addresses or even legitimate emails and domains to fool users into believing that the email was from a known entity or a person that they know. An SPF can be used for handling forged email and help detect and reject these forged emails.

The SPF protocol allows a domain to authorize the hosts that will use its domain name. Also, the host can be used to configure and check the authorization. This way, an SPF can reduce the number of forged emails quite significantly.

To Conclude

We hope this article gave you some information regarding how to fix an SPF permerror for better protection of our SMTP. An SPF permerror is an important SPF error that should be resolved as soon as possible. Resolving these errors as soon as possible will give you better SPF authentication and significant rise in email deliverability.

Static Routing Contabo Problem solved


Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface         UG        0 0          0 eth0  U 0 0         0. eth0

Remove from static table route this to permit to reach the internal network ip always passing through the closed router

ip route del via dev eth0


[root@mail ~]# netstat -rn

Kernel IP routing table

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface         UG        0 0          0 eth0


How to Build Your SPF Record in 5 Simple Steps

from here

spf syntax documentation here

To protect your customers, your brand, and your business from phishing and spoofing attacks, you must authenticate your email. SPF (Sender Policy Framework) is an authentication protocol that allows senders to specify which IP addresses are authorized to send email on behalf of a particular domain.

An SPF-protected domain is less attractive to fraudsters and is therefore less likely to be blacklisted by spam filters. SPF also ensures that legitimate email from the domain is delivered.

Ready to create your SPF record? Follow these five simple steps.

Step 1: Gather IP addresses that are used to send email
The first step to implement SPF is to identify which mail servers you use to send email from your domain. Many organizations send mail from a variety of places. Make a list of all your mail servers, and be sure to consider whether any of the following is used to send email on behalf of your brand:

  • Web server
  • In-office mail server (e.g., Microsoft Exchange)
  • Your ISP’s mail server
  • The mail server of your end users’ mailbox provider
  • Any other third-party mail server used to send email on behalf of your brand

Step 2: Make a list of your sending domains
Chances are, your company owns many domains. Some of these domains are used to send email. Others are not.

It is important to create SPF records for all the domains you control, even the ones you’re not mailing from. Why? Because once you have protected your sending domains with SPF, the first thing a criminal will do is try to spoof your non-sending domains.

Step 3: Create your SPF record
SPF authenticates a sender’s identity by comparing the sending mail server’s IP address to the list of authorized sending IP addresses published by the sender in the DNS record. Here’s how to create your SPF record:

  • Start with v=spf1 (version 1) tag and follow it with the IP addresses that are authorized to send mail. For example, v=spf1 ip4: ip4:
  • If you use a third party to send email on behalf of the domain in question, you must add an “include” statement in your SPF record (e.g., include:thirdparty.com) to designate that third party as a legitimate sender
  • Once you have added all authorized IP addresses and include statements, end your record with an ~all or -all tag
  • An ~all tag indicates a soft SPF fail while an -all tag indicates a hard SPF fail. In the eyes of the major mailbox providers ~all and -all will both result in SPF failure. Return Path recommends an -all as it is the most secure record.
  • SPF records cannot be over 255 characters in length and cannot include more than ten include statements, also known as “lookups.” Here’s an example of what your record might look like:
  • v=spf1 ip4: ip4: include:thirdparty.com -all
  • For your domains that do not send email, the SPF record will exclude any modifier with the exception of -all. Here’s an example record for a non-sending domain:
  • v=spf1 -all

Congratulations! You’ve created your SPF record. Now, it’s time to publish it.

Step 4: Publish your SPF to DNS
Work with your DNS server administrator to publish your SPF record to DNS, so mailbox providers can reference it.

If you’re using a hosting provider such as 123-reg or GoDaddy, then this process is fairly simple. If your DNS records are administered by your ISP or if you aren’t sure, then contact your IT department for support. Email service providers typically publish SPF records for sending domains on your behalf.

Step 5: Test!|
Test your SPF record with a SPF check tool. You will be able to see what recipients see: a list of the servers authorized to send email on behalf of your sending domain. If one or more of your legitimate sending IP addresses is not listed, then you can update your record to include it.